Many people note their passwords down in eg. a text document. Not a great practice, but password management is a pain for most people. So when they do that, their editor might auto-capitalize the first character.
And then you see it's capitalized and change it.
No, even if you fix it... it will went wrong on the moment you click enter to save.
Some mobile keyboards are just dumb enough to fight against users even they explicitly change it back. Some will have a option to disable it, but some probably won't.
Hashing takes a lot of CPU time. And btw you don't even need to change the database schema. You could encode the version in the password field itself. Django does this and it works great
Hashing one or two 10 char strings takes basically no time on even old mobile hardware.
Good password hash algorithms specifically are designed to take a while. They add latency to the subsequent page load when you click “submit”.
Hashing takes a lot of CPU time. And btw you don't even need to change the database schema. You could encode the version in the password field itself. Django does this and it works great
The database would contain existing passwords without normalization. You also you have to hold the unnormalized password. Super silly to do that to save a few processor cycles on login.
It's amazing how much misinformation is in this thread. You should do further reading on password hashing and rethink whether you really have to store two different passwords...
Is this implemented by Facebook holding 3 hashes of your password? It doesn’t save your actual password clear text (or encrypted clear text), does it? A related question: when a password system tells me I need to change my password, and it has to differ by 3 letters from my previous password, is that system storing my password text rather than the hash of the password? Is that safe?
They wouldn't have to store 3 hashes, would they? They could just get the hash of each of those transformations, e.g., reverse case, get hash. If the transformation make the incorrect password into the correct one, it will match the original hash.
Oh you mean the client sends 3 hashes and backend validates if just one matches?
This is a well-understood feature. Facebook does the same thing[0]. Quote: Facebook actually accepts three forms of your password: * Your original password. * Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word. * Your original password with the case reversed, for those with a caps lock key on. [0]: https://www.zdnet.com/a…
Is this implemented by Facebook holding 3 hashes of your password? It doesn’t save your actual password clear text (or encrypted clear text), does it? A related question: when a password system tells me I need to change my password, and it has to differ by 3 letters from my previous password, is that system storing my password text rather than the hash of the password? Is that safe?
To your related question, on the rare systems where I’ve had to do that, I’ve always (to the limit of my memory) had to submit “old password” “new password” “new password again”, so the old password would be available in plaintext client side (and still able to be verified server side after hashing).
This doesn't bother me that much, but what really grinds my gears is how many sites won't let you log in with the correct username and password. I don't care enough about the account to want to set up 2FA, and I'd rather preserve a bit more privacy by not sharing my real phone number or another email address. Some sites seem to insist, and I think it's more about advertising and anti-spam than actual security. Yahoo…
Or the ones that had silently truncated your password (e.g. JetBlue truncating to length 10) in every input and login box so the stored password isn’t what you think it is.
Then one day stopped doing truncating … but only in some boxes, not others.
This is a well-understood feature. Facebook does the same thing[0]. Quote: Facebook actually accepts three forms of your password: * Your original password. * Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word. * Your original password with the case reversed, for those with a caps lock key on. [0]: https://www.zdnet.com/a…
That may have been the case in 2011 when that article was written, but I have just tested this now and my facebook does not accept my password with the case reversed by having the caps lock key on.
Using letters in a phone number as a mnemonic, or just to flow better, is not a "rare case." You should revise your regex to accept letters, then whether you store them internally as letters or convert to the corresponding numbers is up to you.
That makes sense if you are making a contact book or social profile. I was focusing on the case where I want the number as contact information. I want to validate up front that it is a number that I can actually call and don't really care about how the user wants to format it.
Right, but it's user-hostile. I prefer thinking of, and typing, my phone number as a mix of numbers and letters... so why won't you allow me to do so?
It is result of calling `exit.__str__()`. This function could have called exit() itself instead.
I'd say that would be much more surprising and unintuitive behavior just for the sake of slightly more convenient REPL use. I wouldn't want stringifying any function to automatically call it. What if you store the function somewhere and print it for debugging, and then have to figure out why your program keeps crashing when you try to just print a list of functions? Besides, you usually have a more convenient exit av…
Please never implement a password feature without reading more about how passwords should be stored.
good lord, why would you ever expect psuedo code to be my level of understanding of how to store a password. i don't ever store passwords. hashes only.
Because the pseudo code looks quite bad? The clause should pick the user not the password or hash or anything like it. The hash (and possibly salt etc) should come back via the selected column list. The other way round is inviting trouble and could indicate a poor understanding, though I agree they shouldn't be so snarky without some explanation.