views:

497

answers:

10

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

A: 

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.

Jonathan Sampson
I really like OpenID :) but I wonder if phishing is going to be a big issue when it becomes more mainstream for users :(
Arthur Thomas
A: 

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.

David Thomas
+1  A: 
  1. Do you need username to be case sensitive?
  2. 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.
Shoban
+1  A: 

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).

Ofri Raviv
+4  A: 

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.

Arthur Thomas
Note that some people share an email address (husband and wife with the same email is quite common), so it's important to allow users to select something else.
Sal
I wouldn't really worry about that to much then. They can share the same account elsewhere as well. If it is important to keep that separate somewhere they can get another email account. I understand the issue, but I just don't see it as a big concern.
Arthur Thomas
A: 

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.

stealthdragon
+1  A: 

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.

Erik
+2  A: 
  1. You should let users change their username. What's the reason for stopping them?
  2. Do you really need to make usernames case sensitive?
  3. 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.
  4. 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.
Rich Adams
This is good advice. Remember, unless you're a bank or facebook, you need users more than they need you and building a cumbersome account registration that forces someone to create yet another impossible-to-remember login just so they can post a dumb comment or something can drive them away very easily.
Sal
A: 

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.

ADummy
A: 

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
joberror