Basic cyber security says that passwords should be encrypted and hashed, so that even the company storing them doesn’t know what the password is. (When you log in, the site performs the same encrypting and hashing steps and compares the results) Otherwise if they are hacked, the attackers get access to all the passwords.
I’ve noticed a few companies ask for specific characters of my password to prove who I am (eg enter the 2nd and 9th character)
Is there any secure way that this could be happening? Or are the companies storing my password in plain text?
I’m assuming they’re plain text. There’s is no perceivable way they can only use those data points to to figure out which hash it is. Unless of course they’re using their own “hashing” function which isn’t secure at all since it’s probably reversible.
Theoretically they could take those two characters + a salt and then also store that hash. So there it is technically a way to do it although it’d be incredibly redundant, just ask for the actual password at that point.
Please don’t do that. Brute force attacks are very easy on single characters, even two of them.
Yes, I did a reply about this above because this idea has been suggested a few times and it’s truly a bad security move. I’d prefer they just encrypted it and made sure the key was stored separate from the database. That’s more secure than this idea.
Perhaps they validate the passwords client side before hashing. The user could bypass the restrictions pretty easily by modifying the JavaScript of the website, but the password would not be transmitted un-hashed.
It is worth pointing out that nearly any password restriction like this can be made ineffective by the user anyway. Most people who are asked to put a special character in the password just add a ! to the end. I think length is still a good validation though and it runs into the same issue @randombullet@lemmy.world is asking about
How would they validate individual characters client side? The set password is on the server.
When you are filling out the web form with your password it’s stored plain text in the web browser and accessible via JavaScript. At that point, a JavaScript function checks the requirements like length and then does the salting/hashing/etc and sends the result to the server.
You could probably come up with a convoluted scheme to check requirements server side, but it would weaken the strength of the hash so I doubt anyone does it this way. The down side of the client side checking is that a tenacious user could bypass the password requirements by modifying the JavaScript. But they could also just choose a dumb password within the requirements so it doesn’t matter much… “h4xor!h4xor!h4xor!” Fits most password requirements I have seen but is probably tried pretty quickly by password crackers.
OP asked about validating specific characters of the password. Commenter then said it has to be stored in plain text for that to work. Then you commented about client-side validation. Which I really don’t see has anything to do with the stuff before in this thread?
Commenter said it has to be plain text server side. You implied validating client side would allow storing hashed passwords and still validating individual characters of the password. Which I asked how that would work. Your answer to that seems to give a general view of password handling on forms and validation?
I have never heard of anything secure doing that. Assuming they have taken security steps, it would mean they recorded those characters in plaintext when you set your password, but that means that at least those characters aren’t secure, and a breach means some hacker has a great hint.
When the hashing occurs, it happens using the code you downloaded when you visit the site, so it’s your computer that does the hash, and then just the hash is sent onwards, so they can’t just pull the letters out of a properly secure password.
A secure company would use two-factor authentication to verify you above and beyond your password, anyway, since a compromised password somewhere else automatically compromises questions about your password.
A lot of banks in the UK do it. They normally have a secondary pin that they will ask for 2 or 3 characters of.
This means that if you log in and get keylogged/shoulder surfed etc they don’t get the full pin. The next time you login you will get asked for different characters.
Not great, but not awful either - going away now that 2fa is more common
A secondary pin is a bit better but characters from the actual password (that you have to enter anyway) adds nothing to security from that kind of intrusion.
Unless they hash and store various combinations of characters in addition to, or instead of, the whole password. I haven’t heard of anyone doing this. If you were to pad them with a unique salt and a pepper before hashing each combination, you could end up with something more secure than just hashing the whole password. But hashing the whole password, if done properly, is already secure enough so this would seem like needless complication unless there’s some unusual concern about the password being intercepted in transit, and in that case you’d have other problems anyway.
I have heard of this thing of asking for selected characters of a static second authentication factor (e.g. a PIN), but not of a password itself. And now that we have proper 2FA systems I haven’t seen anything like that in a while.
Do they always ask for the same characters? I’d imagine they could hash the password as well as saving only the 2nd and 9th characters as plaintext. Still a bit of a security risk but not nearly as bad
Theoretically they could hash the the two characters with a salt and store it that way, but extremely unlikely they’d actually do that. And also fairly pointless. But still technically possible.
I wrote a comment about this in this thread. Just to add that a salt doesn’t add complexity to the brute forcing of a password, it just makes it so you need to brute-force each one separately.
Hashing pairs of characters would be extremely insecure.
It’s always 2 characters, but I can’t remember if it is the same ones every time
I’ve noticed a few companies ask for specific characters of my password to prove who I am (eg enter the 2nd and 9th character)
They what?!
This is a huge red flag and should not even be possible for your primary password, if they are following basic security principles. Are you sure this isn’t a secondary PIN or something like that?
NatWest in the Uk does it for both the password and the pin, has been since I signed up like 10 years ago. I assumed they do it so you don’t enter a full password that someone could access later. No idea how they work out but they are big and I assume if it was insecure they’d have had issues by now. I assume they store the letter groupings in advance.
I would assume they have the whole password in plain text, then. Not much you can do about it, just make sure you’re not re-using any part of that password for other services. And if you are, then you should start changing them all to something unique, ideally with a password manager like Keepass or BitWarden. This is a good habit anyway, because you can never really know how companies are handling their IT security.
Crazy that that hasn’t become an issue for them yet! Thanks for the tips! I used to be pretty bad with my passwords but I’m reformed and using KeePass for everything these days.
One of the greats back on r/TalesFromTechSupport had a story about how his company (a telco, iirc) did the following with passwords:
- Discard everything after the 8th character.
- Replace everything that isn’t a number or unaccented letter with the number 0.
- Store this “hash” in plaintext.
A user could have a password that they thought was “štr0ng&longsupermegapasswordofdoom” and be able to log in with it, but what was stored was “0tr0ng0l” and they would have been able to log in with something like “!tröng$lips” as well.ä
None of this was communicated to the customers.
Obviously, once in a while a customer would call support because they were sure they had made a mistake entering their password but were able to log in anyway. And tech support had strict instructions to gaslight those customers that they must have entered the password correctly and just thought they made a mistake.
Hot damn 🙈
I assume if it was insecure they’d have had issues by now.
At this point, it’s okay to assume that they have had issues and they haven’t disclosed them.
Can a company be sued for storing pw in plaintext?
I’m not sure if they can be sued for that. Surely you can sue them if they get hacked and you’re negatively affected, though.
So i get the feeling that storing pw in plaintext is heavily frowned upon but not illegal
Not ilegal. Just very stupid. Like it’s not illegal to leave your house’s front door unlocked.
deleted by creator
Shamir’s secret sharing, which was new to me, still means the password must be unencrypted though!? Otherwise there’s no secret that can be shared. You can’t get individual characters of non-reversible-hashed passwords.
Reading the Wikipedia page about Shamir’s secret sharing I don’t see anything about sharing part of the secret data, only that the decryption key is split-shared.
[This comment has been deleted by an automated system]
So in this case the shared partial secret key would be a part of the secret. That seems like a bad idea, bad practice for security. But I see how it’d work.
[This comment has been deleted by an automated system]
Good question. A lot of banks in Europe use this type of setup, where it will ask you for 3-4 characters of your pin/password, both to login and to confirm transactions. I always thought it was weird but never thought about the security implications.
I do have this with my bank as well, but I have always had to enter a full username and different password before it asks for those
One of the main differences between hashing and encrypting is that encryption is réversible by some means, while hashing isn’t. The irreversibility is what makes it so ideal for storing a password in a way that definitely can’t be used to get the original password back, even if someone steals the whole database with the passwords in it.
Those companies that ask for specific characters might be encrypting the passwords, but they definitely aren’t hashing them.
I always figured they checked the plaintext locally before hashing and sending it to their server, but I don’t really know.
This is it.
It seems a lot of people have trouble distinguishing between what’s simply happening in their browser, and what’s being sent back to the server. I mean, I get it; it’s confusing, even to the people creating the tech, let alone a casual netizen. It’s a good question, and you can’t fault anyone for wondering what’s what.
No, in fact asking these questions is a fantastic thing.
Speaking of questions - I imagine there is a day to use the built in dev tools in the browser to verify that the particular site does this, but I don’t know how. Do you happen to know how I might?
I remember signing up for a site a few years ago and they emailed me my confirmation, with my password, in plaintext. I was absolutely shocked
Just a heads-up, your comment is posted twice.
Not sure if there are any browser dev tools that do what you’re specifically asking. It’s more that you need to know what to look for in the source code, and the tools just aid in finding/editing/testing things. Even if you learn a dozen coding languages, and know what to look for, they may be sending the password as plain text and then doing the dirty work server-side. Maybe they send a single-use key to your browser, hash and send the password with that, then re-hash it on the server, with a private key. There are numerous ways to accomplish the task, and I’m glad I didn’t start any arguments with my simplistic “this is it” statement.
All of that said, I’ve been out of practice for quite a while, and I was never a wizard anyhow. So, maybe someone else can offer a catch-all solution, but I really doubt it. Regardless, being aware and vigilant puts you way ahead of the pack, so nice work there.
They could hash pairs of characters on password creation and store those. Seems like more data points to guess the original password, but maybe the math is hard enough it doesn’t do much.
If it’s uniquely salted (and especially if they use a secret pepper too) it might not help with guessing the password, because now you have to crack several hashes of long random sequences of bytes instead of just one.
I’m finding it hard to see how it would be more secure. If I understand what the other comment meant, they would have something like:
password123 = ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94fWe’ll assume they pick 4 random pairs
3rd + 5th (sw) = 7865b7e6b9d241d744d330eec3b3a0fe4f9d36af75d96291638504680f805bfd 9th + 11th (13) = 3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278 2nd + 5th (aw) = f5fe88ee08735ae259265495a93c8de2b0eacfecf0cd90b5821479be3199fa8c 6th + 8th (od) = 32f30ea0e83c41a331c4330213005568675f7542c25f354ebb634db78cc30d12Assuming all 128 7bit character options are used and ignoring dictionary or optimized attacks the complexity of the full password is 7x11 or 77 bits (or 151,115,727,451,828,646,838,272 combinations). So with just the password hash that’s how many tries you need to exhaust every possible option, again without optimizing the process.
But for each of the pairs the complexity is 14 bits or 16,384 combinations. So it would take microseconds to crack all 4 of the pairs. With that information you’d get a password of ?as?wo?d1?3??? (because we don’t know the length) and if they have used a common word or series of words you might have enough information to guess the rest, but even when brute forcing you’ve removed a decent amount of complexity.
Note: This is SHA256. We’re going to ignore salt for this. Salt only increases complexity because you need to crack each user’s password and not able to really use rainbow tables etc.
Unless I misunderstood the idea. In which case, sorry about that.
In all likelihood it is encrypted in a database and the interface to the phone operator only allows them to enter what is said and confirm (although I wouldn’t be surprised of some showing the whole password).
You may be right. I was thinking that the strings would be padded with a random pepper and a unique salt though, before hashing. So the string “sw” might become “swrP86#UlRA64%KGjBICfyO!6” with the unique salt and then “awrP86#UlRA64%KGjBICfyO!6L6ZCf3#T##ssUPjfOMXL^YGZ" with pepper added before hashing, while the string “od” might become "odjaSmh&1$n1##1#400AjQE10kXL6ZCf3#T##ssUPjfOMXL^YGZ” (salt shown in italics). Then you’d be trying to crack these long strings rather than just two-character strings. Of course, if someone steals the DB they would have the unique salt, which would reduce the difficulty to that of guessing two characters plus the pepper (assuming the pepper is stored securely elsewhere), but that’s still quite difficult.
Full-stack dev here, not necessarily in answer to OP’s question, but in my experience it is a pretty standard practice that when you log in to a service, the web page sends your unhashed creds to the server, where your password is then hashed and compared to the stored hash. Via HTTPS/TLS/SSL, this is a reasonably secure practice since the creds are still encrypted while in transport. Hashing is a computationally expensive process that (before the advent of WASM) wasn’t really feasible to do on the client side.
What is WASM ?
Web Assembly. Pretty neat tech if you read up on it.
I’ve only seen this as a second factor after entering a full password. Although it has mostly been replaced by actual 2FA now. Last time I remember this type was on the uk gov student finance website
The 2 occasions I can think of, it was characters from my main password. Both were during contact with the Support teams. I no longer have service with either of the companies (due to unrelated reasons)
Did you have to give those characters directly to the support staff?
On one occasion, yes, over the phone.
The other I was in a web chat on the company’s website and they provided a link to a page on the same website where it asked for the characters
The way I’ve seen this done before, it was not for a password, but for a token entered after the password was entered. No, the token is not encrypted, and therefore it would not be secure for the service to use it as a password.
This is typically used for a secondary authentication factor in most instances, such as a service ID number after you’ve already provided a username, and entered at the same time as a password.
It is not possible for them to securely be storing the password yet being able to retrieve individual characters at the same time.
There are at least two components relevant for entering credentials:
-
the webclient running on your pc/phone
-
the company server
You open a registration page on a website and your browser downloads the application to your device (just like downloading an app from a store).
The application gives you a form to create an account or a login page where you enter the password/username.
The client then checks if the credentials you entered contain the correct amount of special characters and numbers.
Only after that the credentials are hashed/encrypted and send to the server.
You didn’t read the post’s description.
How is it possible that a company asks you to provide the second letter of your password to prove identify? Surely this would either mean the passwords are stored unencrypted. Or they’re using some other form of very dubious security.
Sorry, I misunderstood your post. They could do this by doing the process I described above AND storing parts of your password. Without further research, this sounds insecure though.
E.g. your password is: SuperSecure? The hash of your password is: 15837A4C3B Your client sends the hash and the characters 0,2,4 to the server: S p r They can then ask you for single digits of the password.
Another possibility is that they could encrypt the characters with a key to build a more secure value to transmit. As the others have said, this is possibly unsecure too.
In general: it’s services are either comfortable to use or secure. You can achieve both on a basic level, but not on a higher level.
Is not “possible” insecure. It’s wildly insecure. Encrypting single digits? I mean, anyone could bruteforce them by hand alone.
Funny thing is: I’m probably quicker typing a 20 character password than finding out which symbol is at index 5.
-
Any password restriction that LOWERS entropy is a bad restriction.
No, I’m not answering the question, I know. But I’m answering the better question, which is “is this a stupid thing to ask of a password?”, and yes it is.
