Username + password in hetzelfde veld, veilig?

[Rekcor]

Voor een webapplicatie wil ik het de gebruiker wat gemakkelijker maken om in te loggen. Stel nu dat ik dit wil door hem de mogelijkheid te geven om zijn username en wachtwoord in dezelfde <input type="password" /> te typen?

Dus stel je hebt user piet, klaas en marie met de wachtwoorden abc, def, ghi. Deze staan (natuurlijk) gesaltedhashed in de db:

username	pass	salt
piet	$@#^@35462reGdfsg3w$%^@GT8456yhgdf	$%23452REFGSDFGSDFw54634
klaas	FGDHTRY($&REBFVJDFGuefghewrt65243wTDFS	Gdfgsdfg%$^#$%êgsdfG%$#W
marie	^$#%23wtgsdfGDFTYG%$^*&%^%95yjcfgd2342	gdfsgsdf$#^@3576547urdHDFGsdf

Als Piet wil inloggen, typt hij in: pietabc

Het systeem haalt alle usernames uit de users tabel, en kijkt of die voorkomen in het usernamepassword. In dit geval zal hij 'piet' vinden. Vervolgens knipt het systeem 'piet' van het usernamepassword af, zodat 'abc' overblijft. Tenslotte zal het systeem piet en de gehashte 'abc' checken om de gebruiker in te loggen.

Stel dat dit ook handig is voor de gebruiker, welke security issues zitten hier aanvast? Ik ken http://security.stackexch...te-user-no-username-field e.d., maar die gaan ervan uit dat je helemaal geen username hebt.

Mogelijke issues:
Gebruiker 'piet' en 'pietje' --> pietje zal niet kunnen inloggen, omdat het systeem 'piet' zal afknippen. (oplossing: match eerst de langste username en dan pas de kortste, echter, als het wachtwoord van 'piet' begint met 'je', krijg je weer een probleem; in dit specifieke geval speelt dit niet, want de gebruikers zijn collega's en het zijn er max 10).

[barry457]

issue zal zijn dat als er iemand mee kijkt, hij meteen het wachtwoord weet. Je hoeft namelijk alleen maar 1 veld in te vullen. Mocht je wel het invoerveld hashen, dan zou het wel kunnen. Ik vraag me alleen af of dit nou zo een correcte manier is.

Aangezien het collega's zijn, lijkt het me dat ze moeten inloggen op een pc, waarom geen single sign on gebruiken?

[RM-rf]

Rekcor schreef op donderdag 19 juni 2014 @ 12:35:
Voor een webapplicatie wil ik het de gebruiker wat gemakkelijker maken om in te loggen.

gebruiksgemak <> veiligheid...
ultiem gebruiksgemak is natuurlijk geen login te hebben, of enkel een username als login.


het kunnen zien van een loginnaam, vind ik echter evenzeer een groot gebruiksgemak...
zowel bij het zelf invoeren, of bv doordat deze na een inlogpoging teruggetoond wordt (en je kunt zien of je daarin een fout gemaakt hebt mogelijk)..
ook bv paswoord-managers maken hierin logins 'herkenbaar'... en dat verlies je alemaal enkel als je maar een loginveld wilt tonen...

ikzelf vind het verlies aan functionaliteit eigenlijk zwaarder wegen dan de eenmalieg 'tab' of click die je bij het invoeren kunt besparen

[Rekcor]

In de praktijk wil ik trouwens twee opties aanbieden.

Links 'quick login' met mijn usernamepassword-veld
Rechts 'normal login'

[RM-rf]

Rekcor schreef op donderdag 19 juni 2014 @ 12:43:
In de praktijk wil ik trouwens twee opties aanbieden.

Links 'quick login' met mijn usernamepassword-veld
Rechts 'normal login'

dat is helemaal vaag en wonderlijk... om een extra veld invoeren te besparen, wil je de gebruiker opzadelen met het moeten maken van een ongebruikelijke en onduidelijke 'keuze' die hij moet maken...?
Hij moet opeens gaan beslissen hoe of waar hij wil of kan nloggen op twee verschillende plaatsen?

sorry, maar op mij komt dat over alsof je juist een hindernisparcours van je inlogprocedure aan het maken bent uit een soort van conceptuele dev-liefde..

less=more... houd standaard functionaliteiten juist zo duidelijk en simpel mogelijk en dat is vaak gewoon 'wat de mensen kennen'..
usability komt vaak daarop uit

[ Voor 6% gewijzigd door RM-rf op 19-06-2014 12:46 ]

[Rekcor]

Dank, maar mijn vraag ging niet over usability, maar over veiligheid.

Eerst wil ik weten of het veilig is, dan of het handig is voor de gebruiker.

[LiquidT_NL]

Ik denk dat dit een beetje overdesign is. Je doel is specifiek deze oplossing, en omdat je nu extra zaken (zoals een keuze tussen normal/quick) gaat implementeren om om de problemen heen te werken, gaat het oorspronkelijke doel (gemak) er onder lijden a.g.v. onduidelijkheid en afwijking van de standaard.

[Kalief]

Browsers hebben de mogelijkheid om ingevulde velden te bewaren zodat als ze ergens een naam- of emailveld herkennen ze je een eerder ingevulde naam of adres kunnen laten kiezen. Dat doen ze niet bij wachtwoordvelden. Als in jouw geval het wachtwoord ook in het naam/email-veld komt te staan wordt dat een volgende keer ook weergegeven.

[NMe]

Hoe kom je er in hemelsnaam bij dat de gebruikersnaam én het wachtwoord in hetzelfde veld invullen "makkelijker" is? Om te beginnen kan je browser daar geen touw aan vastknopen en dus het wachtwoord niet onthouden voor je gebruiker, en verder maak je het jezelf verdomd lastig en daardoor onveilig. Dit nog naast de verwarring voor gebruikers die ineens iets anders moeten doen dan ze gewend zijn van elke andere website.

Stel nou iemand heeft als username piet en als wachtwoord jansen1234, en een andere user heeft als naam pietjansen en wachtwoord 1234. Hoe weet je wie je moet matchen? Wie log je in?

Doe gewoon een username en een door crypt (en niet domweg door SHA-1 of MD5!) gehaald wachtwoord. Dát is veilig, makkelijker en bovendien wat gebruikers gewend zijn.

[ Voor 3% gewijzigd door NMe op 19-06-2014 13:06 ]

[SaphuA]

.

[ Voor 130% gewijzigd door SaphuA op 31-01-2022 14:56 ]

[P_de_B]

NMe schreef op donderdag 19 juni 2014 @ 12:52:
Doe gewoon een username en een encrypted (niet gehasht!) wachtwoord. Dát is veilig, makkelijker en bovendien wat gebruikers gewend zijn.

Whut? Waarom moet je een wachtwoord encrypted opslagen en niet gehasht?

[DiedX]

Absoluut overdesign. Wil je makkelijk inloggen, gebruik dan een Yubikey of een user-certificaat. IMHO: Dit is onzin...

[Bosmonster]

RM-rf schreef op donderdag 19 juni 2014 @ 12:46:
[...]


dat is helemaal vaag en wonderlijk... om een extra veld invoeren te besparen, wil je de gebruiker opzadelen met het moeten maken van een ongebruikelijke en onduidelijke 'keuze' die hij moet maken...?
Hij moet opeens gaan beslissen hoe of waar hij wil of kan nloggen op twee verschillende plaatsen?

sorry, maar op mij komt dat over alsof je juist een hindernisparcours van je inlogprocedure aan het maken bent uit een soort van conceptuele dev-liefde..

less=more... houd standaard functionaliteiten juist zo duidelijk en simpel mogelijk en dat is vaak gewoon 'wat de mensen kennen'..
usability komt vaak daarop uit

En dat allemaal om een enkele tab-toetsaanslag te voorkomen...

[Allard]

Met een gebruikersnaam en wachtwoord in hetzelfde veld is er feitelijk sprake van login met uitsluitend een gebruikersnaam, zonder wachtwoord. de gebruikersnaam is van Piet -> Pietabc geworden.
Dat is niet veiliger en ik vraag mij ernstig af of het ook prettiger is voor de gebruiker. Zeker wanneer je dan ook nog meerdere loginopties gaat aanbieden.
Om zonder wachtwoord in te loggen scheelt de gebruiker 1 keer klikken, maar daarvoor moet hij wel extra klikken om een andere loginoptie te selecteren en ook nog eens nadenken wat er nu precies van hem wordt gevraagd.

[Herko_ter_Horst]

Kortom:

• Niet veilig (afkijken/sterretjes)
• Niet functioneel (waar houdt de username op en begint het password)
• Niet handig (gebruikers zijn het niet gewend, browser/password manager kan er niet mee omgaan)
• Niet doen (dus)

[NMe]

SaphuA schreef op donderdag 19 juni 2014 @ 12:53:
@Nme: Waarom zou hashen met een salt niet veilig zijn? Ik vind encrypten wel erg lelijk. Als er op je server wordt ingebroken zijn alle wachtwoorden te achterhalen.

P_de_B schreef op donderdag 19 juni 2014 @ 12:55:
[...]

Whut? Waarom moet je een wachtwoord encrypted opslagen en niet gehasht?

Mijn fout, ik bedoelde niet encryptie maar specifiek crypt (of vergelijkbare functies voor andere talen). Ik zal mijn post even aanpassen.

[Barryvdh]

NMe schreef op donderdag 19 juni 2014 @ 13:05:
[...]


[...]

Mijn fout, ik bedoelde specifiek crypt (of vergelijkbare functies voor andere talen). Ik zal mijn post even aanpassen.

In PHP kan je beter gewoon http://php.net/manual/en/function.password-hash.php gebruiken (of https://github.com/ircmaxell/password_compat voor PHP<5.5)

[NMe]

Barryvdh schreef op donderdag 19 juni 2014 @ 13:07:
[...]

In PHP kan je beter gewoon http://php.net/manual/en/function.password-hash.php gebruiken (of https://github.com/ircmaxell/password_compat)

Password_hash is zo te zien PHP 5.5+ en daarmee vrij nieuw. Begrijp ik goed dat het hele punt van die functie is dat de PASSWORD_DEFAULT-waarde verandert met de tijd om geschiktere algoritmes te gebruiken zonder dat je daarvoor je code moet aanpassen? Want ik zie het verder niet veel meer of minder doen dan crypt.

[Cor453]

NMe schreef op donderdag 19 juni 2014 @ 13:16:
[...]

Password_hash is zo te zien PHP 5.5+ en daarmee vrij nieuw. Begrijp ik goed dat het hele punt van die functie is dat de PASSWORD_DEFAULT-waarde verandert met de tijd om geschiktere algoritmes te gebruiken zonder dat je daarvoor je code moet aanpassen? Want ik zie het verder niet veel meer of minder doen dan crypt.

De github link die hij erbij zet is een implementatie van hetzelfde < PHP 5.5. Het is een erg makkelijke library waar gewoon nette encryptie achter zit!

[Barryvdh]

NMe schreef op donderdag 19 juni 2014 @ 13:16:
[...]

Password_hash is zo te zien PHP 5.5+ en daarmee vrij nieuw. Begrijp ik goed dat het hele punt van die functie is dat de PASSWORD_DEFAULT-waarde verandert met de tijd om geschiktere algoritmes te gebruiken zonder dat je daarvoor je code moet aanpassen? Want ik zie het verder niet veel meer of minder doen dan crypt.

Het hele punt van die functie is vooral om het makkelijker te maken, met een simpele interface. Het is de combinatie van password_hash, password_verify en password_needs_rehash.
Het grote voordeel is dat je niet zelf je salt hoeft te genereren, want dit is wat er vaak fout ging. Het gebruik van crypt is zelf inderdaad niet zo moeilijk en doet hetzelfde.
Wat de password_compat library doet is deze functies implementeren in puur PHP, zodat je ook op PHP5.3/5.4 dezelfde interface kan gebruiken, met een veilige salt. Het is ook gemaakt door dezelfde persoon als die de RFC implementeerde. Zie ook de RFC met verder uitleg over hoe/waarom.

These hashing APIs will initially be thin wrappers around crypt() to allow for automatic salt generation and better error checking. The APIs are designed such that they can easily be extended in the future as additional strong hashing algorithms are introduced into PHP's core (Such as scrypt).

[ Voor 15% gewijzigd door Barryvdh op 19-06-2014 13:28 ]