5 ms·
So they hash both versions of the password? Or how does this work?
by chris_l 5y ago
So they hash both versions of the password? Or how does this work?
- baybal2 5y agoI believe they don't hash the password. They can't know the capitalised version of my password unchanged from nearly 17 year ago.
- Dylan16807 5y ago...and if they remove the capital?
- williamdclt 5y agoOf course they hash the password. Of course they don't know the capitalised version of your saved password, but they can know the capitalised version of the password you just entered
- baybal2 5y agoBut how did they know which punctualion characters to remove from the password? You may try 2 versions of first letter, but do they go as far as bruteforce removing all the % character combinations from the password, unless they did remove them all?
- achairapart 5y agoFrom the first answer: > Looks like the app is clever enough to try changing the case of the first letter if the first attempt fails. Still, looks like a compromise between usability and security/reduced password entropy.
- morsch 5y agoOr just normalize the password by making the first character either lower- or uppercase both when checking and setting it.
- Raed667 5y agoIt would be more complicated to do this once you stored millions of passwords. So now you have to create 2 flows, those before the new policy and those that were set after the normalization.
- weird-eye-issue 5y agoIf your storing millions of passwords surely a version field and an if statement is not going to be a huge concern
- Raed667 5y agoIt is definitely more complicated than changing the case and running the hash again
- weird-eye-issue 5y agois_password_valid = hash_password(normalize_password_case(password) if version == 1 else password) == hashed_password
- pixl97 5y agoAre we doing this client side or server side? If you're actually using a 'strong enough' hash to prevent easy cracking if your hashed password database is leaked then you're doubling the server load which can be quite substantial in some cases.
- weird-eye-issue 5y agoIt's only being hashed once... And obviously this is server side
- markenqualitaet 5y agoWhy?
- cotillion 5y agoThey probably just do two password checks.
- nimchimpsky 5y agoI doubt that very much
- chris_l 5y agoThat's what I meant... hash both versions when logging in.
- OJFord 5y agoAh, it's a bit ambiguous though: not GP, but I read you as meaning do they store both versions' hash and check against either. Actually I realise GP is equally ambiguous. But I read that as (and my own assumption would be) frontend retries with the variation, backend verifies against the same only one stored.
- mnahkies 5y agoYeah we did it this way on an app I worked on in the past, try the verbatim input and then a couple of minor variations in casing if it didn't work. I've also found that for email fields you need to be careful to normalize the input (trim, casing) as safari had a habit of autocorrecting the first character to be a capital
- alin23 5y agoIt’s very nice that you do that! I find apps that don’t trim the whitespace for the email field so annoying in terms of UX. I usually use a Text Replacement shortcut to fill in my emails (e.g. “gml” fills in my GMail address, “cld” my iCloud address etc.) and that always inserts a space after the email and I have to manually fiddle with the cursor to delete it.
- Levitz 5y ago>I've also found that for email fields you need to be careful to normalize the input (trim, casing) as safari had a habit of autocorrecting the first character to be a capital Why is that relevant? The standard technically allows for case sensitivity but nobody does it
- doubleorseven 5y agoThey send it once over the wire but salt it twice if the first attempt fails and the request originated from a mobile app. UX is all around us.
- coredev_ 5y agoSadly it can also mean that they save your password in a form that enables them to read it if they need/want it.
- iso1210 5y agoAssuming the password is sent over the wire (rather than the salt being sent to the client, the client doing the hash, and sending the hash), the password will be stored in memory while the login process runs Normal password code would be if (doHash(password+salt) == storedHash) { failedLogins = 0; return 1; } failedLogins++; return 0; This would presumably be if (doHash(password+salt) == storedHash) { failedLogins = 0; return 1; } if (doHash(swapFirstLetterIfClientIsMobile(password)+salt) == storedHash) { failedLogins = 0; return 1; } failedLogins++; return 0; So while the password is 'stored' in the server side heap, it's no different to normal password 'storage' If the hash is done in the client it's the same, just the client sends two attempts rather than one.
- the_gipsy 5y agoEven if it’s encrypted, they could send both forms. Edit: not a good idea.
- squeaky-clean 5y agoI'm no security expert, but this would let someone try two unrelated passwords at once and so probably wouldn't be done client-side.