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?
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.
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.
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.
This seems somehow worse than simply requiring the same few characters each time, since they would either have to store the complete passwords in plaintext, or compute and store the hash for every permutation of 2-3 characters, which is wildly inefficient. You’d also be susceptible to leaking your password if for some reason you are under long term surveillance, since at some point you would presumably have provided all of the characters making up the password.
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 passwordEdit: I was wrong it seems; you’d still end up with something insecure. 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.
If they hash a subset, then those extra characters are literally irrelevant, since the hash algorithm will exclude them. Like if they just hashed the first 5 characters, then “passw” is the same as “password” and all those permutations. Hashing is safe because it’s one-way, but simple testing on the hashing algorithm would reveal certain characters don’t matter.
Protecting a smaller subset of characters in addition to the whole password is slightly better but still awful. Cracking the smaller subset will be significantly easier using rainbow tables, and literally gives a hint for the whole password, making a rainbow table attack significantly more efficient. Protecting the whole thing (with no easy hints) is way more secure.
It also adds nothing to keylogging, since it’s not even a new code, it’s part of the password.
There was a time where that level of security was acceptable, and it still could be ok on a closed system like an ATM, as the other reply to my comment pointed out, but this kind of protection on a standard computer is outdated and adds holes.
Less secure if you come at it from the perspective of cracking the password, but probably more secure in real-world terms.
If you type in your bank password and somebody’s compromised your browser, they now have your entire password.
If you type in the third, fourth and eighth digits and somebody’s compromised your browser, they still can’t access your account.
Obviously full 2FA is probably better, but
A bank requiring a smartphone to bank with them is probably a no-go
A bank probably has to deal with some of the least technical users that are out there
If it’s too hard for certain users to engage with the system correctly, they’ll try to sneak around it in ways that could compromise their security more than if the bank had just gone with the specific digits thing in the first place.
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.
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.
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.
Assuming 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.
The issue with salt is that it is stored with the password hash. So you’d pretty much get that information with the password. It’s only designed to make sure the hash won’t be the same for the same password on other users, not to make breaking the hash any harder on its own.
You could store it (and/or pepper) wherever the password is actually checked and splitting it would help. But I cannot imagine they’re doing that. It’s far more likely they’re encrypting the password and keeping the key off the database server. Meaning they need to get both, to get passwords.
Yes, my understanding is that the pepper is usually supplied from another source (not stored in the database), specifically to make it more difficult for anyone who steals the database to crack the password hashes. It would mean that if you stole this hypothetical db with two-letter subsets of the password in it, and got the salts too, you’d still be cracking the hash of a much longer string. But if you figured out that one string (pretty hard to do), you’d have the whole lot.
If you have the password hashes, you almost certainly have the salts. Salts prevent the same password used by different users having the same hash, but if you’re bruteforcing, they don’t really add to complexity.
Bruteforcing 2 characters + a salt is computationally the same as bruteforcing 2 characters.
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.
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.
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
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.
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)
Even if they somehow manage to secure the password properly while still being able to know a specific character from that password, having support staff handle that information directly seems very very fishy. All in all, it doesn’t speak for their security practices. Even if they have sone form of protection for the specific characters stored separately, it would reduce the overall security because parts of your passwords are more easily guessable. In the worst case they simple store your pw in plain text and on top of that they might supply that information to the support staff.
Also, I’ve seen this when you have an alternate form of authentication like a password you type in full, or an existing session token. In those scenarios, you could probably use some sort of symmetric key encryption to encrypt the secondary password with the primary password / session token in such a way that you aren’t storing the key and can’t decrypt it, but that you can check specific digits on command.
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.
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.
Something fun you can do is set your password to an eicar test string. That should break things of they are running any av and storing the password in clear text
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.
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.
Theoretically: Shamir’s Secret sharing with a limited amount of secret material available to the helpdesk could form a relatively secure method to validate k knowledge of the password without disclosing all of it.
Practically: pretty sure they just store (part of) your password in plaintext. Getting SSS working can be difficult and it’s much easier to just pretend your password is stored safely instead.
In between those two you have intermediate options (hashing a bunch of combinations of position + salt + character with a very large amount of rounds) but if we’re talking about two characters, you may as well just store the characters in the dagaabse directly
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.
With SSS the secrets are calculated either on your end (in the browser) or at the moment you would normally hash the password when you first set it. And yes, the server does receive some secrets as well.
What you basically do is encrypt something with the combined secret key. The helpdesk only has one or a few parts of the secret key themselves. They need one or more secrets from you to derive enough of the secret key to decrypt the message. That message could literally be “congratulations you found the secret key” for all intents and purposes.
If they enter the secrets you provide (say, secrets derived from the second and ninth position, and the appropriate characters in a password) and the message gets decrypted successfully, the other side will know that you are who you claim you are, without ever disclosing all of your secret material. It doesn’t necessarily matter which part of the secret your share, as long as you share enough to successfully decrypt a message, but the agents probably want random positions to make sure someone who overheard you on the phone can’t just reuse the letters you used.
This is quite tricky to set up so I doubt it’s commonly used. It’s also vulnerable to potential brute forcing if the secrets stored by the bank can be extracted, but if the helpdesk doesn’t have direct server access only the IT people inside the bank (who can probably read the password you submit to their servers anyway) can really brute force anything.
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.
It’s not necessarily bad practice, that’s exactly how such a system should work, assuming the keys material is good enough not to be brute forced easily. SSS is better if you combine strong key material (actual cryptographic keys, for example) but reading out ECDSA keys over the phone is quite the hassle.
I’ve never actually encountered a business that asked for my password over the phone and I would feel sketched out regardless of how good their implementation might theoretically be. It’s better than voice identification, but I’d rather keep my passwords to myself.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
No such thing. Ask away!
!nostupidquestions is a community space dedicated to being helpful and answering each others’ questions on various topics.
Rule 1- All posts must be legitimate questions. All posts titles must include a question.
All posts must be legitimate questions, and all post titles must include a question. Questions that are joke or trolling questions, memes, song lyrics as title, etc. are not allowed here. See Rule 6 for all exceptions.
Rule 2- Your question subject cannot be illegal or NSFW material.
Your question subject cannot be illegal or NSFW material. You will be warned first, banned second.
Rule 3- Do not seek mental, medical and professional help here.
Do not seek mental, medical and professional help here. Breaking this rule will not get you or your post removed, but it will put you at risk, and possibly in danger.
Rule 4- No self promotion or upvote-farming of any kind.
That’s it.
Rule 5- No baiting or sealioning or promoting an agenda.
Questions which, instead of being of an innocuous nature, are specifically intended (based on reports and in the opinion of our crack moderation team) to bait users into ideological wars on charged political topics will be removed and the authors warned - or banned - depending on severity.
Rule 6- Regarding META posts and joke questions.
Provided it is about the community itself, you may post non-question posts using the [META] tag on your post title.
On fridays, you are allowed to post meme and troll questions, on the condition that it’s in text format only, and conforms with our other rules. These posts MUST include the [NSQ Friday] tag in their title.
If you post a serious question on friday and are looking only for legitimate answers, then please include the [Serious] tag on your post. Irrelevant replies will then be removed by moderators.
Rule 7- You can't harass or disturb other members.
If you vocally harass or discriminate against any individual member, you will be removed.
Likewise, if you are a member, sympathiser or a resemblant of a movement that is known to largely hate, mock, discriminate against, and/or want to take lives of a group of people, and you were provably vocal about your hate, then you will be banned on sight.
Rule 8- All comments should try to stay relevant to their parent content. Rule 9- Reposts from other platforms are not allowed.
Let everyone have their own content.
Rule 10- Majority of bots aren't allowed to participate here.
Unless included in our Whitelist for Bots, your bot will not be allowed to participate in this community. To have your bot whitelisted, please contact the moderators for a short review.
Partnered Communities
You can view our partnered communities list by following this link. To partner with our community and be included, you are free to message the moderators or comment on a pinned post.
Community Moderation
For inquiry on becoming a moderator of this community, you may comment on the pinned post of the time, or simply shoot a message to the current moderators.
Matrix Chat Room
To find & join our chat room, log into fluffychat.im(or any other matrix client) and put #nostupidquestions:matrix.org on the search bar.
Credits
Our breathtaking icon was bestowed upon us by @Cevilia!
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 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.
This seems somehow worse than simply requiring the same few characters each time, since they would either have to store the complete passwords in plaintext, or compute and store the hash for every permutation of 2-3 characters, which is wildly inefficient. You’d also be susceptible to leaking your password if for some reason you are under long term surveillance, since at some point you would presumably have provided all of the characters making up the password.
It’s normally an additional password/code, so it’s probably stored in plaintext.
The random character selection is what makes it useful. Stops someone who just captured your details from logging straight in (probably).
2FA is superior in every way to it. Most have now switched to sending you a chip & pin card reader to generate OTPs.
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 passwordEdit: I was wrong it seems; you’d still end up with something insecure. 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.
It’ll be less secure.
If they hash a subset, then those extra characters are literally irrelevant, since the hash algorithm will exclude them. Like if they just hashed the first 5 characters, then “passw” is the same as “password” and all those permutations. Hashing is safe because it’s one-way, but simple testing on the hashing algorithm would reveal certain characters don’t matter.
Protecting a smaller subset of characters in addition to the whole password is slightly better but still awful. Cracking the smaller subset will be significantly easier using rainbow tables, and literally gives a hint for the whole password, making a rainbow table attack significantly more efficient. Protecting the whole thing (with no easy hints) is way more secure.
It also adds nothing to keylogging, since it’s not even a new code, it’s part of the password.
There was a time where that level of security was acceptable, and it still could be ok on a closed system like an ATM, as the other reply to my comment pointed out, but this kind of protection on a standard computer is outdated and adds holes.
Less secure if you come at it from the perspective of cracking the password, but probably more secure in real-world terms.
If you type in your bank password and somebody’s compromised your browser, they now have your entire password.
If you type in the third, fourth and eighth digits and somebody’s compromised your browser, they still can’t access your account.
Obviously full 2FA is probably better, but
If it’s too hard for certain users to engage with the system correctly, they’ll try to sneak around it in ways that could compromise their security more than if the bank had just gone with the specific digits thing in the first place.
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.
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
Assuming 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.
The issue with salt is that it is stored with the password hash. So you’d pretty much get that information with the password. It’s only designed to make sure the hash won’t be the same for the same password on other users, not to make breaking the hash any harder on its own.
You could store it (and/or pepper) wherever the password is actually checked and splitting it would help. But I cannot imagine they’re doing that. It’s far more likely they’re encrypting the password and keeping the key off the database server. Meaning they need to get both, to get passwords.
Yes, my understanding is that the pepper is usually supplied from another source (not stored in the database), specifically to make it more difficult for anyone who steals the database to crack the password hashes. It would mean that if you stole this hypothetical db with two-letter subsets of the password in it, and got the salts too, you’d still be cracking the hash of a much longer string. But if you figured out that one string (pretty hard to do), you’d have the whole lot.
If you have the password hashes, you almost certainly have the salts. Salts prevent the same password used by different users having the same hash, but if you’re bruteforcing, they don’t really add to complexity.
Bruteforcing 2 characters + a salt is computationally the same as bruteforcing 2 characters.
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
I always figured they checked the plaintext locally before hashing and sending it to their server, but I don’t really know.
that doesn’t explain the scenario described in the post
You’re right, I misread the post. What sites have done that? I’ve been fortunate to never encounter any.
A bunch of European banks.
Might be time to switch banks…
They all do it. It’s perfectly secure if you don’t implement it in a naive way.
No, they aren’t storing your password in plaintext.
How is it implemented?
There’s a security stack exchange on this exact question here.
Storing your credentials in plaintext would be insane, illegal, and would never pass any kind of audit.
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.
Yes, 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.
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
Even if they somehow manage to secure the password properly while still being able to know a specific character from that password, having support staff handle that information directly seems very very fishy. All in all, it doesn’t speak for their security practices. Even if they have sone form of protection for the specific characters stored separately, it would reduce the overall security because parts of your passwords are more easily guessable. In the worst case they simple store your pw in plain text and on top of that they might supply that information to the support staff.
There’s a security exchange thread on it here
It looks like there are certain kinds of algorithms you can run that give you this property.
Also, I’ve seen this when you have an alternate form of authentication like a password you type in full, or an existing session token. In those scenarios, you could probably use some sort of symmetric key encryption to encrypt the secondary password with the primary password / session token in such a way that you aren’t storing the key and can’t decrypt it, but that you can check specific digits on command.
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.
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.
Something fun you can do is set your password to an eicar test string. That should break things of they are running any av and storing the password in clear text
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.
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.
Theoretically: Shamir’s Secret sharing with a limited amount of secret material available to the helpdesk could form a relatively secure method to validate k knowledge of the password without disclosing all of it.
Practically: pretty sure they just store (part of) your password in plaintext. Getting SSS working can be difficult and it’s much easier to just pretend your password is stored safely instead.
In between those two you have intermediate options (hashing a bunch of combinations of position + salt + character with a very large amount of rounds) but if we’re talking about two characters, you may as well just store the characters in the dagaabse directly
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.
With SSS the secrets are calculated either on your end (in the browser) or at the moment you would normally hash the password when you first set it. And yes, the server does receive some secrets as well.
What you basically do is encrypt something with the combined secret key. The helpdesk only has one or a few parts of the secret key themselves. They need one or more secrets from you to derive enough of the secret key to decrypt the message. That message could literally be “congratulations you found the secret key” for all intents and purposes.
If they enter the secrets you provide (say, secrets derived from the second and ninth position, and the appropriate characters in a password) and the message gets decrypted successfully, the other side will know that you are who you claim you are, without ever disclosing all of your secret material. It doesn’t necessarily matter which part of the secret your share, as long as you share enough to successfully decrypt a message, but the agents probably want random positions to make sure someone who overheard you on the phone can’t just reuse the letters you used.
This is quite tricky to set up so I doubt it’s commonly used. It’s also vulnerable to potential brute forcing if the secrets stored by the bank can be extracted, but if the helpdesk doesn’t have direct server access only the IT people inside the bank (who can probably read the password you submit to their servers anyway) can really brute force anything.
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.
It’s not necessarily bad practice, that’s exactly how such a system should work, assuming the keys material is good enough not to be brute forced easily. SSS is better if you combine strong key material (actual cryptographic keys, for example) but reading out ECDSA keys over the phone is quite the hassle.
I’ve never actually encountered a business that asked for my password over the phone and I would feel sketched out regardless of how good their implementation might theoretically be. It’s better than voice identification, but I’d rather keep my passwords to myself.