17
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’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.
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.
The most secure way this could happen is them storing the specific character separately. It reduces security of your password if that plaintext character is compromised but you could still store the rest of the password securely.
You could even salt and hash the one character with a large salt to keep it behind a one-way function, and then the agent would need to enter it and confirm via the system, but that would reduce any downside of the one or two characters being compromised.
It's weird either way though.
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
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.
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
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
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 = ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
We'll assume they pick 4 random pairs
3rd + 5th (sw) = 7865b7e6b9d241d744d330eec3b3a0fe4f9d36af75d96291638504680f805bfd
9th + 11th (13) = 3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278
2nd + 5th (aw) = f5fe88ee08735ae259265495a93c8de2b0eacfecf0cd90b5821479be3199fa8c
6th + 8th (od) = 32f30ea0e83c41a331c4330213005568675f7542c25f354ebb634db78cc30d12
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).
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.
view more: next ›
this post was submitted on 11 Jul 2023
17 points (100.0% liked)
No Stupid Questions
35694 readers
1182 users here now
No such thing. Ask away!
!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:
Rules (interactive)
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.
Credits
Our breathtaking icon was bestowed upon us by @Cevilia!
The greatest banner of all time: by @TheOneWithTheHair!
founded 1 year ago
MODERATORS