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.
They could hash the xth letters in a seperate column that are hashed separately, but it's likely they are just storing plain text.
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~~ Edit: 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.
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 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.
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:
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 🙈
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.
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 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.
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
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.
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.
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.
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.
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.
!nostupidquestions is a community dedicated to being helpful and answering each others' questions on various topics.
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rule 1- All posts must be legitimate questions. All post 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 intentionally annoy, mock, or harass other members.
If you intentionally annoy, mock, 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.
Our breathtaking icon was bestowed upon us by @Cevilia!
The greatest banner of all time: by @TheOneWithTheHair!