Edit Jan 18th 2010,
Is there any symbol that should NOT be allowed to use in a password?
=========================================
Hi,
I am wondering what 'common' policy out there for username/password for creating a new account on a website.
This is currently what I have:
===========For username ==================
Length between 6 and 20 characters
Spaces are not allowed
Usernames are case sensitive
can contain lettlers, numbers, and symbols
* Uppercase letter (A-Z)
* Lowercase letter (a-z)
* Digit (0-9)
can not change after registration
===========For Password=============
6-20 chars long
can contain lettlers, numbers, and symbols
* Uppercase letter (A-Z)
* Lowercase letter (a-z)
* Digit (0-9)
* Special character (~`!##$%^&*()+=_-{}[]\|:;”’?/<>,.)
password is encrypted in the database
password can be sent to the email address when requested
Thanks
For username you can make it case sensitive but I probably wouldn't allow 'similar' matches.
For example it would be annoying to have these usernames on the site as all difference account:
Luigi
LUIGI
luIgI
LUigi
It could lead to griefing (people using similar account names to mock/harass someone). And it will just be confusing. And it causes problems when you have similar characters ilike l I i 0 o O.
I would rather use an email address as a username though since they will remember it. It is annoying having different usernames for lots of different sites. Email addresses are guaranteed to be unique :)
The password restrictions seem fine. As for that it is just a matter of how strong you want to force their passwords to be. Although, I would not send passwords through email. Email is insecure and the reset password method is preferred here.
password is encrypted in the database
password can be sent to the email
address when requested
Encrypted? No. Hashed? YES. If its hashed, you can't get the password back from the hash to send it to the user, and this is as it should be.
If the user forgets a password, you reset it with a temporary one, and email THAT to the user, so they can define a new password.
NEVER store plain-text or encrypted passwords in your database; if your software can unencrypt it, an attacker who got his hands on your database can do it, too.
You should let users change their username. What's the reason for stopping them?
Do you really need to make usernames case sensitive?
Don't just encrypt the password and send it to the user. Use salted hashes to store it, and if the user forgets it, generate a new one for them.
Don't bother with password restrictions at all, they just make it easier to see the search space of passwords people can try with a brute-force attack. Instead just use a list of passwords people shouldn't use (dictionary words, etc). If I want to use an entire Japanese novel for my password, that should be my choice. If you're storing them correctly as salted hashes, then the hashes will always be the same size anyway, regardless of how long my original password was.
Do you need username to be case sensitive?
Do not send out password when requested. Instead send them a password reset link. This way people wont complain that their account might be compromised even if some oe has access to the user DB.
1 practice that is becoming more and more common, is not to have usernames and passwords on your site, but to rely on OpenID or other Identity validation providers.
And sending user passwords in email is a horrible habit that must be stopped. if the user forgot his password, send him a random one, and ask him to change it. please, don't send him HIS password in email (as we all know, most users use the same password on many apps/sites).
Why are you enforcing a maximum limit on usernames? Does it seriously affect you, or compromise your database, if someone wants -for whatever reason- to use a particularly long character-string for their username?
If you're encrypting the password the upper limit doesn't really make sense, since the hash (whatever function you use) will produce a consistent length string more or less regardless -according to my understanding of hash functions- of length. I'd also consider running the submitted -and hashed/encrypted- password against known rainbow tables, to try and enforce strong passwords. But this may, or may not, be possible depending on the available APIs or licensing terms of such sites that feature searchable rainbow tables.
One approach would be to not place many restrictions on passwords but have a list of passwords that users can't use. Here is the list of passwords that can't be used on Twitter:
http://www.techcrunch.com/wp-content/uploads/2009/12/Twitter-banned-passwords.txt
This would filter out the weakest passwords while still giving your users to choose the passwords that they want.
Don't store it if you don't need to...
Is OpenID not an option?
If you do, make it strong...
I like the idea of using an email address as the "username," eliminating the need to store it later for communication, etc. And as for passwords, encourage "strong" ones. 6-12 characters of random-casing and numbers interspersed.
Not many good reasons to store plain text...
I would then hash the password.
I thing the policy you are using is good. But you should never ever store the password of someone in the database. I would suggest adding the username (If it could not be changed; else maybe the id) and build a hash of that. And always if you check a password you again add the username and build the checksum (sha512 is ok) and test if that is the same as the one stored in the database. Maybe it would be a nice thing to add a constant random salt. (also like the username)
You may get something like sha512("myname_password_4235329659").
That makes using rainbowtable these days almost impossible.
I think You should narrow it this way:
Use:
Email Address as Username;
Password must be strong by forcing a rule as follows:
Alphabets(in small or capital),
Numbers
Characters(#,&,*, !...)
must include at least one of these and must be 6 or more in length
Case sensitivity must be applied when signing in
Hint: Use a password generator as an assistance
A security question and answer for later recovery of username or password or
simply use birth date validation for this
Related
First, I apologise for the question. I know there are a ton of similar obvious questions that ask for how to implement bcrypt in X app, but here I'm asking between 2 strategies.
I just recently implemented bcrypt into the user login. Basically:
User sends credentials to my rest api server
I bcrypt.hash the given password and compare it to the database with a simple where clause as the following:
WHERE mail = $mail and password = $my_just_hashed_password
If I find a user on the database I assume that the given password is correct. Otherwise, I reject the request.
This is almost the same as first selecting the user from the unique mail given and then bcrypt.compare the given password and the hashed one from the database.
My question is, which one is better? I know that the bcrypt hashing function is intended to be used to safely store sensible data, but why not using it to also validate users?
I will provide an alternative answer to the already approved answer, with emphasis on security...
As the email is unique, I would first find the user based on the email alone, get the password from the retrieved user, and compare these using bcrypt. If the email exists, but the password doesn't match, there may be a brute force attack in place, you may want to log these failed attempts so you can lock accounts or add a captcha perhaps to slow down/prevent the attack.
How is this different
ORIGINAL SOLUTION
Get the user from the email and hashed password
If the credentials are right, great, the user can log in. No problems here
If the user is not found, was the email or password incorrect? You can't know with this one query alone.
The potential attacker is free to continue trying to access a potential account by trying different passwords on the inputted email.
ALTERNATIVE SOLUTION
Get the user from the email alone
If the user exists, compare the hashed user password in the DB with the hash password of the inputted credentials (using bcrypt compare).
If the password is incorrect, log this in another table (USER_FAILED_LOGINS), after 3 failed attempts, add a some security measure such as a captcha.
If the password is correct, great, log the user in.
You could of course, use the original solution and just do another query if the credentials were incorrect to figure out if the email exists and implement the security measures at this point. Just be wary of these types of attacks and prevent against them. Also, make sure you are using prepared statements in your SQL.
When you use bcrypt to hash a password correctly, you append a string of at least sixteen random characters to the password and run the whole thing through bcrypt many thousands of times. It should take at least a quarter second to complete the hash algorithm. Then you store the random. string, known as a salt, along with the hashed password.
To verify a password, you extract the salt from the stored password hash, then hash the password you're verifying along with the salt. The two hashes must match.
Because of the salt, there's no way you'll ever be able to compare one hash to another and expect them to be equal.
Read this, please. https://en.m.wikipedia.org/wiki/Bcrypt#Description
Why is this so complex? Because cybercreeps. Because cybercreeps sometimes can steal the users table for a large web app. It is bad enough that they steal the usernames and emails, but we don't want them to steal the passwords too. See Adobe. See Ashley Madison.
Without the random salts, it's possible for attackers to construct lookup tables to help guess passwords from hashes: RAM is cheap these days. The random salts mean that the lookup tables are no longer feasible. You know some user will choose 654321 as a password, and we don't want attackers to be able to search all the passwords for a hashed version of that and other common passwords.
Also, we use the Blowfish cypher algorithm because it is slower than MD-5 and the various SHA hashes. That's good: we want attackers to be faced with a slow hashing algorithm, so they can't guess many thousands of passwords each second. Brute force password guessing is prohibitively time consuming with bcrypt.
Finally, it's a principle of information security to use carefully validated encryption algorithms. It's unwise to roll your own. Assume that the cybercreeps are smarter and more highly motivated than you, and you will be more secure.
Do not use the method you describe, please.
Probably a super basic question. I know many online services hash and salt passwords instead of storing them as plaintext for security purposes. My university's web portal requires students to change their passwords every 6 months. From what I know, the system is built on Oracle software.
My question is, however, how does the system know when my 20 character long password (with capitals, numbers, and symbols) contains 3 characters in the same order as the new password I'm trying to set? If the passwords are hashed, shouldn't the algorithm be one-way? Or is it possible that system encrypts the plaintext passwords and stores them? Wouldn't that be less secure?
Sorry if the question is hard to understand. Let me know if you need me to clarify. Thanks in advance!
If you have to enter your previous password when creating a new one, the system can compare them directly. This could even be done client-side.
EDIT
There are only a few other possibilities
They store your password in plaintext (in which case they should fire their entire IT department)
Their encryption method is two-way i.e. it can be decrypted (in which case they should fire their entire IT department)
They temporarily store your password when you log in. Maybe in a cookie or on the server. (In which case they should fire their entire IT department)
It is likely that the prevoius password table is encrypted (possibly using rot26).
The system can only check if the new password matches the old password exactly (compares the hashes). If it's checking substring matches, the passwords are likely being stored in plaintext.
No bueno.
EDIT: Or what Nick said, of course.
In light of the recent Gawker Media password leak, I've realized that many users share the same passwords. To help encourage stronger passwords, would it be helpful if passwords are constrained to be unique among all users?
One immediate downside I could think of (besides account creation performance?) is being able to know that someone is using a given string as a password. This knowledge, combined with a list of users, could be quite dangerous.
Is there a way to mitigate that downside while retaining the alleged benefits of not allowing repeat passwords?
It's kind of like the XKCD kick bot where you aren't allowed to repeat short, unoriginal sentences like "yah" or "lol".
Edit^2: I thought you could unique-ify against a hash, but as someone pointed out, with varying salts, this would not have the intended effect. Good eye!
absolutely not.
It is critical that no information about passwords be available to users outside the system. If they can easy guess which passwords are in use, by discovering that a password is unavailable, then they can use those passwords on known usernames and get a good shot at gaining access.
An alternative is to find some kind of common passwords database, and prevent any user from using them.
eeeuh
I might be misreading your question, but I hope you do not store the actual password?
You should hash the password with a random salt. That way, there is no way for you to ever tell if one or more users have the same password.
If your systems, in any way, allows you to determine if two or more users have the same password, you are storing the passwords the wrong way.
I would suggest the follwing as you have already mentioned the disadvantage of using "unique# passwords for all
Educate the user's about strong password.
Ask user's to change password regularly.
Keep a "Password strength" meter while they type in the password.
Really don’t
As long as you have salts, the password won’t be stored the same way anyway.
If you want to ensure password security:
Pick a good hash (sha256, blowfish, etc.)
Use salts
Snap-in a password meter with a minimum threshold
A lot of those can be bundled with wordlists
Check out a post I made about it on reddit:
http://www.reddit.com/r/netsec/comments/ektb8/in_the_light_of_recent_gawker_breakout_lets_talk/
If password management is done correctly, the only person who should know their password is the user who created it in the first place. In my web sites, I never store the password in any form. I store a cryptographic hash (SHA-1 or some variant) of that password that is manipulated with some sort of unique "salt" padding. Essentially if two people did have unique passwords, there would be no way to tell.
Most of the passwords on that link you gave are all easily guessed dictionary passwords. Very weak, and easy to brute force. They would all be unallowed by any system with rudimentary password checking.
I'm working on an admin page in PHP in which a user system seems like overkill. I was thinking of just requiring one password to access the admin page, but I'm not sure if would be safe to do so. I can't see any specific security problems that this might pose, can anyone else think of any?
Edit: By "a user system is overkill" I meant that there is not likely to be more than one user.
Complexity of the passwords aside, there are two problems:
The passwords must be unique now
If you have user+pass, users can have the same password. Under your model, they all must have a unique one.
Limited tracability
A good reason for user accounts to see who does what. You remove this, a little, with a general password as you need to assume, again, a one-to-one matching between them, and users. This may or may not be an issue.
For some of my admin pages, I don't really have a "user" so much as I have two tokens that need to be entered (because I'm the only admin).
For general people signing up, though, and if the password is entered by them, this is not an appropriate plan. If it's just for your admin pages for you, and you generate passwords of an appropriate complexity, life will be good.
It suffers from the same issues as a shared login, making it impossible to revoke for a specific user (if someone leaves, a users computer is compromised, etc), along with the issue of being way more open to brute force attacks (as mentioned by others).
For something simple, that doesn't seem to need a full fledged user/pass system, why not use HTTP Auth built into the server? Easy to setup, doesn't need to be shared, but would require no extra code on the admin script.
To sum up what others have said: Fine as long as the password is not simple, but more vulnerable to brute-force attacks.
Solution: You can enforce a password-complexity policy, and you can throttle further login attempts - get it wrong once, next login is artificially slowed 4 seconds. Get it wrong again, 8 seconds, and so on.
Option: Use two fields - username and password - but make the user also just a static value, like the password. Twice the guessing, twice the effort, twice the security (and twice the hassle for users..)
You could actually throw in a CAPTCHA. That would thwart brute-force attacks pretty well.
There is no problems if your admins wouldn't use simple passwords, like 1234567.
I, have the opinion that having a single password makes the system MORE secure (not less), as long as both the password and system are secure.
The reason is that when you have several users, it just takes one of them with a bad password to be the "weak link in the chain"
That said, nothing wrong with it as long as essential security measures are in place - and keep in mind brute forcing is easier (so make sure it's impossible/ineffective)
I would think that for your admin page (one would think the most secure page) that you would want very tight security?
If your "admin" user has a "hard to discover" username and that is paired with a very secure password I would think that this would be a better system.
Ideally I think you would want to have a complex username and password:
e.g.
Username: e4t_Gjw3#gp
Password: q!-gr7cBFL045$bd
Update: based on the comments I thought I would elaborate on why user+pass is more secure than a pass of "e4t_Gjw3#gpq!-gr7cBFL045$bd".
Having both a username and a password doesn't double the security, it does much more than that.
Pretend that usernames and passwords are both 3 characters (from A-Z) no case-sensitivity.
To guess a password, using brute force, you would need up to: 26x26x26 = 17,576 tries.
To guess just a username, same conditions: 26x26x26 = 17,576 tries.
If you had to guess both but they didn't have to match it would be 17,576x2 = 35,152.
However, if you have to guess the username AND find the matching password it is more like:
17,576 usernames * 17,576 passwords = 308,915,776
Of course if you have up to 16 character usernames (using case-sensitivity, numbers, punctuation etc.) and the same for passwords, the number of possibilities is Insanely Huge and thus... secure.
Update2: I seem to have missed typing the key bit of info I was trying to relay in my update. In most systems I've seen or built, the username and password fields have a size restriction built into the SQL columns of 32, or 40, or X characters. In the ones I've seen where there is just a pass column, the size isn't typically doubled to 64, or 80 chars.
Obviously the pass-only column, and set value can be doubled in length to account for the lack of username - but I have rarely if at all seen this done.
As Jake said, there are many reasons not to do this but it depends on what your application is doing. You need to do enough to put amateur hackers off. Make sure the admin use a strong password - 10 digits, with at least one capital and one symbol or something like that.
Most security experts would still frown on this though.
Password only + Captcha is ideal, Captcha would automatically implement rate-limiting and a strong password will make it secure.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
When registering at a site the other day, one of their password requirements was that it couldn't contain any special characters, such as ' " = : ; < > ( )
While this alone doesn't indicate they don't hash their passwords, is it a strong indicator? If the password is hashed, these special characters will be translated into something else, and any harmful SQL will be turned into random characters. By virtue of the fact that they don't allow those characters, does it mean the password will be put into the database without being hashed?
I also registered on another site that appeared to have tight security and had good customer reviews. However, once I completed registration and got their welcome email, it included my password in plain text, which was an unpleasant surprise.
No one advertises their poor security, but what are some warning signs that your password may not be encrypted? Typically, you don't know how poor a site's security is until there is a break-in or massive data theft, and the average person on the site can't tell what is going on with their data.
Someone should create a site where you can highlight sites with poor security to steer customers away or shame the sites into changing their policies. I understand you have to have some trust in third party sites, but what are some warning flags that should turn you off of a site?
Generally you'll only find out when you get a account confirmation email or you ask to "send a new password" and you get the original in plain text instead of a random one or password reset link.
I don't think any stupid rules on what can and can't be in a password are strong indicators. Your best bet is to use strong unique passwords for everything.
Two things come to mind.
A: Just because you received an email with a plain text password doesn't mean it's stored in plain text. We encrypt, and email out in plain text, it's bad practice, but a step up from plain text.
B: Use a password manager if you're worried about this type of thing. You can't control other people's password bad practices, what you can control is your good practices and the damage done if one of your passwords is compromised.
I use KeePass myself. It has a password generator that you can modify the rules to so that you can have super obscure passwords (such as: YhdyLa1PJSftp7) specific to the site's criteria.
The worst sign is if they CAN email you your password in plain text.
There's no guarantee that they're storing it in plain text, but if the encryption they are using is reversible then most of the developers of the site will know how the password is encrypted/decrypted and can probably read it.
Unfortunately, in general there's no way of knowing for sure whether a site stores your unhashed password.
While this alone doesn't indicate they don't hash their passwords, is it a strong indicator? If the password is hashed, these special characters will be translated into something else, and any harmful SQL will be turned into random characters. By virtue of the fact that they don't allow those characters, does it mean the password will be put into the database without being hashed?
No, it doesn't necessarily mean that. p -> q (i.e. allowing special chars -> password hashed (unless their security is laughably bad)) doesn't allow you to conclude ~p -> ~q (i.e. disallowing special chars -> password not hashed). In other words, it is possible that they disallow those characters but do still hash your password.
I also registered on another site that appeared to have tight security and had good customer reviews. However, once I completed registration and got their welcome email, it included my password in plain text, which was an unpleasant surprise.
It is possible that they generated the e-mail while the password was in memory, but only stored a hash. Though e-mailing a plaintext password is, as you say, not good security practice.
If you get an email telling you that they're switching to a new system with a shorter password limit than the current system and that they will automatically truncate the password for you, that's a dead giveaway that they're storing passwords.
It happened to me with an online banking account recently. You would think that they would know better.
BTW, that doesn't tell you that they're stored in plaintext. They may well have been encrypted. But, from a security point of view, that's no better than storing them in plaintext. The actual passwords should never be stored in any form.
By virtue of the fact that they don't allow those characters, does it mean the password will be put into the database without being hashed?
No. It's generally a bad sign if some characters are disallowed (and incredibly irritating if you have a system for making up passwords with punctuation in), but it's not a red flag in itself. There are occasionally other technical reasons to disallow some characters(*), and very often stupid management policy reasons not to.
(*: in particular, HTTP Basic Authentication can't reliably include a ‘:’ character in a username, or any non-ASCII character in username or password.)
However, once I completed registration and got their welcome email, it included my password in plain text, which was an unpleasant surprise.
Yeah. Not good, but again it doesn't necessarily mean they're storing as plaintext; they could be sending the mail and then hashing it after that.
(Probably not though eh!)
what are some warning signs that your password may not be encrypted?
If a ‘recover password’ facility exists that can mail you the password after signup.
Someone should create a site where you can highlight sites with poor security to steer customers away
That would be nice, but then that someone would be constantly harassed by technically clueless but litigation-happy companies. And when most commercial sites are still also vulnerable to simple XSS or XSRF attacks, the list of “sites with poor security” would be much longer than “sites with good security”.