Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Should users be able to enter a password such as " 12345" or "12345 " – a space at the beginning or end? Or would you trim the password to remove the leading or trailing spaces because it may just a typing error.
Yes, they should.
It annoys me to no end when people decide how my password should behave especially when it's nonsensical. I would like more than 8 characters please.
You should be hashing the password, so maximum character lengths and spaces at the end don't matter.
No, you should not trim it.
You require a user to enter the password twice (when creating it) to eliminate typing errors. Therefore a space doesn't matter.
Let me tell you a story.
I needed to create an account on an ecommerce site, so I ran my random password generator to make an 8 character upper/lower/number/punctuation password, pasted it in twice to confirm it, finished registering with all of my personal information, and saved the random password in a local PGP-encrypted file for later use.
Later on I tried logging in, but pasting the password again didn't work. After a bit of testing, I was horrified to find that the site had stripped out all punctuation marks from the original password, in some misguided attempt at sanitization, reducing my password to three easily brute forceable letters.
DON'T trim or sanitize users' passwords.
Never "clean up" a password simply to account for "typing mistakes". This will confuse users and in some cases make it impossible for them to login. In fact, don't ever change a password behind a user's back...always warn them that a password is invalid and let them try a new one.
A good example that I recently ran into was with a 3Com switch. The web interface allowed me to change the admin password, but didn't warn me that the password was limited to eight characters. I entered a password that was longer than eight characters. When I tried to login after the change, it simply rejected my password. If I only used the first eight characters, however, I was able to login (trial and error on my part, not fun).
Passwords these days don't look the way they used to. For instance, my passwords often look like this:
Man, this program is really ticking me off!
You should validate the password with a confirmation field anyway. If they make the typo twice - then you hopefully have a forgot password or a reset feature in place.
The space shouldn't matter as you shouldn't be storing it in plain text.
The moment you make such a decision is the moment you start walking down the path of micro-management (over your users in this case).
Does a password containing a space break your system? Or is it a security risk? Then don't worry. Let your users deal with their own errors, even if that means they have to get frustrated. Their typo should never be your problem.
Space is a regular password character, and you shouldn't remove it.
Since you probably hash the password before storing it in the database, the space will be treated as any other character.
I'm voting for: No, they shouldn't:
There's a big benefit for not allowing users to use spaces at the beginning and end of passwords and that's simply that it eliminates the problem which often arises when a user copies and pastes their password (e.g. from an email) and it includes white space which isn't part of the password.
The user then gets frustrated, thinks the system is broken and contacts support. A developer is promptly pulled onto the project to check the "buggy" login process only to spend a day pulling out his/her hair until he/she realises the problem.
I think enforcing this policy when creating a password solves more problems than it creates.
It is fine for the password to contain it as already mentioned however I would add that when generating new random passwords (say for a sensible reset lost password system) you should avoid generating ones containing such tricky characters.
If the password is sufficiently long and random then this will make up for the restriction of a few tricky characters will make the end user's life considerably easier...
I've been to a conference more than once where someone logged in to their account for a demo after the computer display was already up on the big screen, didn't change focus to the password field correctly, and thus their password was revealed to the entire audience.
Anyone who might have to enter credentials in front of others should consider keeping a trailing space or three in their password, just in case. And when building authentication systems, you should never trim those spaces.
Since it's bad juju to store the password as text, there's no need to trim() the password since it'll immediately be hashed.
...
on a similar note, am I correct in believing that passwords shouldn't need to be regex validated to for sql injection since they'll be hashed and not inserted as plain text in the database?
I don't care. So long as whatever you do to the password when it is being set is also done to it when being entered later on. Trim, truncate, change case, salt, hash, whatever - just do it consistently.
Presumably you aren't storing the actual password anyway, so...
Related
We are writing new applications and in requirements there are some rules about passwords:
cannot contain 6 repeated pharses in a
row
cannot be the same as last 6 passwords
Second point is easy because we have hashes of this passwords but how can we check 6 repeated pharses?
Example:
first password: kotek123
second password: kot453
how can I check subsequence if I just have hash of this passwords? Is it even possible?
How work masked passwords, I mean when password is kotek123 then some banks just want k#t##23 to log in? Do they store hashes of all possibilities?
perhaps, you should store all subsequences and check if any of them have occured in the previous six passwords.
So it's possible, but very uncomfortable for clients and for developers as well . I wouldn't like to use such a system.
Recently we had the same problem in our system, but we didn't want to poison our lives, so we check similarity of last and new password. It looks simple to do, because, usually, when user wants to change the password, he have to give both passwords, last and new.
I'm curious what method you will apply
I don't think this is possible, if you only have the hash value. This is exactly the goal of hashing a password.
By the way, in the example, the passwords are very different. I recomend just using long passwords, with special characters, and check that on the password creation.
I think masked passwords just store some characters in the database
We have achieved internationalization in the application, but now we want to have support for user can enter password in his own language(Arabic, Russian, Chinese) etc. Here the problem is validation gets fail for upper case and lower case characters. So, please help me provide standard validations rules or password policy which can be applied to authenticate user from any language.
I've looked at this many years ago, and I've been told that most of the users are using Password that are ascii characters, because it's not possible to compose complex characters (Kanji) without displaying them on the screen.
Also the new recommendations from NIST is to stop trying to impose specific characters, but just enforce a minimal length of at least 8 characters, and check against a dictionary of known compromised passwords.
I am implementing forgot password feature for my website, and while looking at other websites for best practices, I found that gmail enforces this, no other site I looked at enforced this constraint.
There is a lot of rather out-dated ideas about passwords and password security.
If a user has a password compromised -- and then however many days later they change it -- the attacker is now blocked from the system.
Should that user ever go back and re-use his old password, then the hacker might decide to retry that account/password and regain entry into the system.
Of course, it opens up a whole new set of problems. Make it so a user can't remember his password and they will start writing them on sticky notes taped to their monitor.
Personally? On all the sites I've worked on, I've never thought it important to add password expiration /or/ limits on what passwords may be (re)-used.
I would have thought it provides little to no added security. You are trusting the user to not lose their password but I guess it can go both ways.
If they have to choose a new password then they may have to write it down or be more likely to forget it again however if they have a new password it is less likely that someone who knows a password they use could use it to access your website.
Either way make sure you are storing the hashed password for comparison and not plain text.
I want to to implement password recovery in my web application.
I'd like to avoid using secret questions.
I could just send the password by e-mail but I think it would be risky.
Maybe I could generate a new temporary random password and send it by e-mail but I think it is as risky as the above point.
Can I send a url by e-mail for example http://example.com/token=xxxx
where xxxx is a random token associated with the user. So when the user navigates to that url he/she can reset the password.
When I was in the Air Force the security rule we had was: When setting or resetting passwords, do not send the user id and the password in the same email. That way, if someone is intercepting emails snooping for passwords, he has to successfully intercept BOTH emails, and be able to connect them, to breach security.
I've seen a lot of sites that use the "go to this URL to reset your password". Maybe I'm missing something -- I don't claim to be a security expert -- but I don't see how that is any more secure than just inventing a new, temporary password and sending it. If a hacker intercepts the email, why can't he go to that link and see the new password as well as the legitimate user could? It looks to me like extra hassle for the user with no security gain.
By the way, congratulations on NOT using security questions. The logic of this device escapes me. Since the dawn of computer security we have been telling people, "DON'T make a password that is information about yourself that a hacker could discover or guess, like the name of your high school, or your favorite color. A hacker might be able to look up the name of your high school, or even if they don't know you or know anything about you, if you still live near where you went to school they might get it by tryinging local schools until they hit it. There are a small number of likely favorite colors so a hacker could guess that. Etc. Instead, a password should be a meaningless combination of letters, digits, and punctuation." But now we also tell them, "But! If you have a difficult time remembering that meaningless combination of letters, digits, and punctuation, no problem! Take some information about yourself that you can easily remember -- like the name of your high school, or your favorite color -- and you can use that as the answer to a 'security question', that is, as an alternative password."
Indeed, security questions make it even easier for the hacker than if you just chose a bad password to begin with. At least if you just used a piece of personal information for your password, a hacker wouldn't necessarily know what piece of personal information you used. Did you use the name of your dog? Your birth date? Your favorite ice cream flavor? He'd have to try all of them. But with security questions, we tell the hacker exactly what piece of personal information you used as a password!
Instead of using security questions, why don't we just say, "In case you forget your password, it is displayed on the bottom of the screen. If you're trying to hack in to someone else's account, you are absolutely forbidden from scrolling down." It would be only slightly less secure.
Lest you wonder, when sites ask me for the city where I was born or the manufacturer of my first car, I do not give an actual answer tot he question. I give a meaningless password.
</rant>
First off, do not store a plain-text copy of the user's password, or even an encrypted version. You want to only ever keep a hashed copy of the user's password.
As for recover solutions, I find that the recovery link to change the user's password is the best solution in my experience. It will probably be a bit more convenient for the user, while being largely the same from a security point of view as sending a new random password to be changed after next login. I'd still recommend having the recovery url expire after a reasonable short period of time, as well as only being usable a single time.
Hard to say what you should do, as pretty much any solution to this problem will weaken security. Unless maybe you want to investigate sending an SMS, callback verification, one-time password generators, or other such schemes that take password recovery to a different medium.
However, what you should not do:
Send the password - because after all, as has already been mentioned, you don't have it.
Generate a new temporary password - not only is this as insecure as sending the password, it also leads to the possibility of a denial of service attack. I can go to the site, pretend to be you, request a new password and then (if you haven't checked your email) you can't log in, don't know why and have to request a new new password ...
The token is probably the way to go. Receiving it notifies a forgotten password request, but doesn't take any action unless you confirm. You would also make it a one-time token with a relatively short expiry time to limit risk.
Of course, a lot depends on the application. Obviously protecting financial and other sensitive information is more critical than preventing your account being hacked on mytwitteringfacetube.com, because while it's inconvenient, if someone wants to steal someone's identity on a social network site, they can just open their own account and masquerade with stolen information anyway.
Obviously, you can't send the original password by email, because you're not storing it (right?!). Sending a temporary password (that must be changed, because it only works for one login), and a link to reset the password are equivalent from a security point of view.
I don't unnderstand the attitude towards the secret question method. It's not like I am going to make my password "BlueHouse" and then make my security question "What are your two favorite things?" and the answer "Blue and Houses". The security question is not the magic key to get the actual password. It's usually a way to get a new password sent to the email address on file. I don't know how else you guys do it, but it sounds like you do one of two things.
1) The user clicks a "I forgot my password" button and the new password is sent to the user.
2) The user clicks a "I forgot my password" button and then has to answer a security question before getting the new password emailed to the address on file.
Seems to me that option number 2 is more secure.
Why is sending a token any more secure than sending the password? If an email account has been hacked, it's been hacked. It doesn't matter if there is a link to reset the password, a token, or a new password. Don't forget, most sites don't say "The new password has been sent to the following email address for you to hack into". A hacker would need to guess the email address that needs to be hacked.
I agree with Andy. Aren't security questions normally independent of the password? (mine are) Meaning they have a question and an answer and aren't related to the password. It seems like this is used to prevent spurious password reset requests and actually does have a use.
Imagine - someone could go to a site's "forgot password" utility and enter a zillion email addresses - or just one person they want to annoy. If the password is reset at that point, the people belonging to those email addresses would have to then notice in their email the password reset and login to the site with the reset password next time they went there. With the security question, this isn't as easy for someone to do.
I see Amazon sends a link to the given email. They also require you to enter a captcha to prevent DOS attacks. Because it's a link, I imagine that means they did not reset the password immediately and it would be reset once the user clicks the link. With the scenario above, the user would just see the email and note that "no I didn't do that" and go about their business not having to change their password needlessly. A security question might have prevented the attempt at the beginning and the legit user from getting the email in the first place.
Here's a whitepaper on it:
http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html
This one actually recommends secret questions as a major part of the authentication process. And sending an authentication code via email and requesting it is just an add-on layer you can optionally include.
It really comes down to how much security you want to have. One the one end of the extreme is a password reset process that involves contacting and certifying that you are who you claim to be, e.g. via id, because your mailbox could be compromised as well. Actually, as people tend to use the same password everywhere this is very likely. On the other end there is the standard approach that involves just sending out an email with a random new password.
"Secret" questions and answers are just another form of username and passwords with the fatal flaw that they are usually incredibly easy to guess, so good that you don't want to use them.
To your point about the token, I don't think it makes a big difference in overall security. Whether you send out a token that allows a user to change the password or whether you send out a random password right away doesn't make a big difference.
Just make sure the token is only usable once and preferably only in a limited time span, e.g. +24h after requesting it.
And, as pointed out by previous answers, NEVER EVER store plain passwords. Hash them. Preferably add salt.
Here's how I resolved it:
I added retrieve_token and retrieve_expiration fields to my 'users' table.
The user requests a password reset by providing their email and filling out captcha. A random hashed value is generated for their retrieve_token field - i.e. md5($user_id.time()), while retrieve_expiration will be set to a datetime that expires in next 45 minutes. Email is sent out to the user with a link:
https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570
SSL should be mandatory when authentication is required. You can also add a table for logging reset requests that stores email and the IP address. It helps track down possible brute attacks and you can block attacker's IP if necessary.
You could implement security question for requesting password reset, but I feel captcha would be enough to discourage anyone from repeating the request multiple times.
#Jay. The reason why you go to a URL to reset your password instead of just sending someone a new temporary password is more than just security. Without something like a URL with a token, a person could reset another persons password. There is no need to gain access to the email. If someone had a bone to pick with someone, they could just keep initiating a new password reset. Then the poor target has to logon and change the password again and again.
By sending a token, the user's password does not change until they login with it and confirm it. The spam of reset emails can be ignored. Tokens are just as easy (if not easier) to generate as a new password by using a GUID, it's not really extra hassle for the developer.
Also, because the GUID is unique (a generated password might not be), a token can be tied to a username. If the incorrect username is given on the URL, then the token can be cancelled (i.e. when a different person initiates it and someone intercepts it.. assuming that the username isn't the same as the email).
#Jay. The proper use of security questions is to initiate a password reset email, not for actually resetting the password. Without a mechanism such as a security question, one could initiate a password reset. Althought seemingly beign, sending a reset email could be sent to an email that might no longer belong to the original owner. This is not rare. For example, when employees leave a company, often those mails are forwarded to another employee. A security question, adds a low level of obfucation to that scenario. It also reduces issues where one person keeps initiating a password reset on the wrong account causing some poor sod to get unintentionally spammed. Security question are really not meant to be truely secure, they are just meant to reduce scenarios such as those. Anyone using a security question to actually reset the password is doing it wrong.
Regarding security question/answer. As a user of websites I personally don't use them (I enter garbage in them). But they are certainly not useless or meaningless as some say here.
Consider this situation:
A user of your site has left his desk to go to lunch and didn't lock his workstation. A nefarious user can now visit the page for recovering/resetting password and enter the user's username. The system will then email the recovered/reset password without prompting for the security answer.
Here's an example of how someone did it with Node.js, basically generate a random token, an expiry time, send out the link with the token attached, have a reset/:token route that ensures a user exists with that token (which is also not expired) and, if so, redirect to a reset password page.
http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/
Reading what is currently the top answer to a recent question on how/whether to send users their passwords, I was intrigued that the most popular answer said the following...
storing passwords in such a way that they are retrievable is insecure
using a reset feature with the help of a secret question is a valid alternative
(These two points seem contradictory.)
I use hashed passwords for security, but I've always assumed that the password question and answer scheme are even less secure because they actually give a hint as to what the answer may be. (I often use .NET's default membership provider.)
Is there something I'm missing because I've not bothered to use the question & answer? Are secret question and answers, without incorporating any sort of timed email reset function, any more secure than storing a password in the db?
Follow Up: Microsoft's membership provider uses the same format for storing answers to secret questions as they do for the password. If you specify hashed for the password, then it will store the secret answer the same way.
From the posts below, it appears that, if used, a secret question/answer mechanism should only be used in addition to an email reset scheme, rather than instead of, and should be hashed as well. This, of course, may present problems for people like me who put long random strings in the secret answer section.
Passwords are answers to a 'secret' question. That question is, "what is your password?".
As Scunliffe points out, adding an additional field of user input may or may not increase the security of the password - that depends on the user's practices.
I allow myself to be guided by OWASP here:
They are unacceptable for the
following reasons:
Collection of information about people without their explicit consent
(such as "Mother's maiden name") is
illegal in most privacy regimes. Such
collection is subject to privacy laws,
review and correction by the subject,
and so on.
IT Security Policies and standards such as ISO 27000 prohibit the clear
text storage of passwords, but almost
all Q&A schemes store both the
question and answer in the clear
The information in the answers is public for a goodly portion of the
users of the Internet, and thus is
found using public sources
Edit (2018): OWASP seems to have re-arranged their materials. The wayback machine captured a copy of the original page.
The question and answer idiom has been exploited in many published "email hacks" (example)- I'd certainly avoid using it.
Secret questions and answers are only as secure as the user makes them to be. If someone knows anything about you, they can answer an easy question and reset your password. I'm guessing answers are also hashed, so that the answer is not directly stored. But again, knowing the answer to the question is all it takes.
A hashed password stored is about as secure as most applications get, and that's fine because it's one way, and thus the plain text is never stored nor can it be retrieved.
I would argue that a secret question/ answer combination is just another form of "password". I would then go on to suggest that a secret answer is probably weaker than a regular password, as there is rarely any suggestion that it should be anything other than regular words that are susceptible to dictionary attacks. In most cases, the dictionary space of the answer is significantly shortened by the context of the question (scunliffe's exception noted, however).
i would use a secret question to determine if I should or shouldn't send them a newly generated password via an email. Never to let them set a new one. At the end of the day though, it all comes down to make it as secure as it needs to be. If you're an online bank or a networking site makes a huge difference.
One site I've been on (bank or health insurance) required me to answer six secret questions. For a password reset, they'd choose three of those at random and require me to answer them.
In addition, I presume they'd only store the hashed answers, not the plain text version. As DDaviesBrackett has said, the password is a secret question.
I feel like part of your question is being overlooked. Cause like you I see how we are somehow overlooking the common sense that if you should not store their password in plain text yet you are willing to store their answer to their 'secret question' in plain text and then allow them reset their password via a link sent through email, than why even have a secret question and just email them their the reset link. Of course you could just as easily encrypt the answer to the question.
It seems that many people, myself included, write their question/answer in some encrypted where the question does not provide a hint, but I'm always asking myself when I create these - "if I don't remember the password that I am going to be using every time I come to this site, how will I ever remember my answer that I made up 2 years ago and have never used."
My Opinion: The whole idea of the 'secret question' is just a sense of false security, as if adding the addition of the secret question is going to make the process of hacking into my account so much harder that the one extra step will frustrate the hacker and cause him to give up.
It seems more likely that it will just provide a clue to a friend or family member you wants to screw with me.
It depends also how related the secret question / answer are.
Case in point, when I'm presented with the option to put in a question I put in something like:
Question: Groovy Broccoli?
Answer: International Space Station 431
These are not actual question/answers I use, but I can assure you that the questions I use provide no clue whatsoever as to the answer.
If you can get into the system by using the secret question, then that system is just as secure as the method with which the secret question is stored.
However, if a user uses their same password on other systems, then at least making sure the password is hashed keeps that user's password from being outted on other systems, like their online bank.
The crux of the security of the secret question usually lies in an alternate trusted communication medium. If the user answers the 'secret question' correctly, the server should provide a random password via the trusted channel (e.g. email address).
Then, using that random password (which is as safe as the user's email), he can use it to log in and change the password to something else.
That depends on the security needs you require... And once they have already answer that part.
The only thing i have to add, its that you use MD5 encryption for storing passwords, and other sensitive data. Be aware that on the present time its next to impossible to discover the "phrase" encrypted by MD5. You can find loads of articles talking about it. And isn't difficult to implement in your projects.
Regards.
Fábio Antunes
"Greetings, Professor Falken."
or
why it is not a good idea to base any authentication scheme on non-secret, non-random-"ish" responses.
And, if you try to be a little tricky and choose random-"ish" responses to the notorious maiden-name-questions and are able to remember them AFTER you have forgotten your password (and probably have changed it a few times since setting the "secret question".
Nay, the whole secret-questions scheme is botched from the start. For a start, the question is not secret but revealed to anybody claiming to have mislaid your password.