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.
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 @[email protected] is asking about
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?
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!
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 @[email protected] 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?
They could hash the xth letters in a seperate column that are hashed separately, but it’s likely they are just storing plain text.