Minimum & Maximum for username/password

[Lobang Trader]

Hi all,

I am trying to create a username and a password class.

I would like to know what are the RECOMMENDED minimum and maximum length
for both fields?

These fields will be something like this:

private static final int DEFAULT_MINIMUM_LENGTH = ??????
private static final int DEFAULT_MAXIMUM_LENGTH = ??????

I can easily specify my own values but I would like the classes to be
scalable and caters for future needs. Hence, I would like them to be
globally accepted.

While at it, what are the taboo characters for both values -
username/password?

Thanks in advance.

 

[Chris Uppal]

I would like to know what are the RECOMMENDED minimum and maximum length
for both fields?

I doubt if you'll get users to accept a minimum of more than 6.

I don't seem much point in having a maximum.

While at it, what are the taboo characters for both values -
username/password?

Why have any ?

There may be business reasons for dissalowing some characters in user names,
<tab> for example would not look good on a generated report. But that's a
business decision.

An argument could be made that forbidding " and ' would make SQL-injection
attacks less likely, but my personal opinion is that anyone who assembles SQL
statements by concatenating user-supplied strings should be shot (just as a
matter of course) so the restriction would -- at best -- encourage a false
sense of security.

-- chris

 

[Guest]

Depends on your clients, server, and method of storing them. Are you
going to use a web app, Applet, Java application, or application written
in another language as your client(s)? Each has its own issues with
character encoding outside latin-1.

Why have any ?

There may be business reasons for dissalowing some characters in user
names, <tab> for example would not look good on a generated report. But
that's a business decision.


An argument could be made that forbidding " and ' would make SQL-injection
attacks less likely, but my personal opinion is that anyone who assembles
SQL statements by concatenating user-supplied strings should be shot (just
as a matter of course) so the restriction would -- at best -- encourage a
false sense of security.

-- chris

As a side note, you should properly escape any data before sending it to a
database or web page.

HTH,
La'ie Techie

 

[Michael Scovetta]

Lobang,
I would recommend not setting a default min/max length for
usernames (or, if you do, make it something like 300 characters or
something, and for passwords, they should be as long as the user
wants, and just store/compare the hash of the password. So if I want
War and Peace (the contents) to be my password, that's cool.

My $0.02.

Michael Scovetta

 

[Yoyoma_2]

Lobang,
I would recommend not setting a default min/max length for
usernames (or, if you do, make it something like 300 characters or
something, and for passwords, they should be as long as the user
wants, and just store/compare the hash of the password. So if I want
War and Peace (the contents) to be my password, that's cool.

Not to disagree, but i disagree. ;-)

Firstly if these logins are going into a db, allowing arbitrary lengths
can lead to very avoidable performance issues. Why have a "Text"-type
datafild when you can use the faster varchar( 32 ). if you will have
many logins, that will lead to big performance and storage gains.

Why not just limit it at 32? Why allow a 15 megabyte username? Or a
user name that someone types in as "LobangTrader " the space being
added by the the user's kid pressing on the space bar while on the
phone. You should at least trim it.

Also the day that you might want to do LDAP synchronization or
synchronization with any other service that needs a login, you might
have problems since half your uses use @ in there names, but XXX server
doesn't allow it. Allowing names of like 32 characters, no spaces, only
letters, numbers and _,- and the other common ones would go a long way.
Furthermore the day that maby you want to make a script to give them
access to a unix or ftp account, its there. That's scallability baby

Also for passwords, i would reccomend not storing passwords at all. You
can do an MD5 password check really easily, and it frees the server from
any liability lawsuits about poeple saying "someone stole my password
off your server".

So what you do is you get the login and password, and MD5 the password
and store that into your database. Then when the user tries to logon,
you get the (HTTPS!) form data and use the java.securirty.MessageObject
class to get an MD5 encoder. MD5 is like a "code" for a string. Its
called a "one-way cypher" because you encode it one way and its
virtually impossible to decode it from the MD5 back to the original string.

Now since you are using MD5, you shouldn't allow to long of passwords
because your probability of collision (two different passwords having
the same MD5) go up as the string is big. I'de just limit it to 64
characters. A 64 character password is a pretty good limit.

Now you may ask, what if the user forgets his/her password and needs a
"get my password" e-mail? well just don't use them. Send them an e-mail
with a couple security questions, going to a specified link code that
expires in XX time like paypal, e-bay etc. Its not really hard to
implement and its pretty secure. Put a couple sample questions like
"what's your favorite food", "Your pet's name", "The street you grew up
on" etc. With that you don't need to store passwords and that helps
free your company of this type liability. (yee! ). Contact a lawyer
to make sure though since i'me not a lawyer i can't say what frees
you from liability.

At work, a friend of mine actually made an MD5 cypherer in javascript so
even the post data, through HTTPS, was beying encoded. That means that
we didn't even know the password at any given time throughout the
process. Kind of cool to treat log ins and passwords without knowing
the passwords

Anyway thats my 0.02$ CAD so that brings you up to real money now!

 

[Carl Howells]

At work, a friend of mine actually made an MD5 cypherer in javascript so
even the post data, through HTTPS, was beying encoded. That means that
we didn't even know the password at any given time throughout the
process. Kind of cool to treat log ins and passwords without knowing
the passwords

I was agreeing until here. But that is *BAD*. That completely defeats
the purpose of hashing the passwords to begin with.

The purpose of hashing passwords is to make it very difficult for
someone who gets your password database to be able to log in to your
system. But for that to work, you have to be able to trust that the
hashing is working correctly. If that's done client-side, you can't
trust it at all. It is trivial to send any value you want in a POST
request.

Remember, security is all about what agent needs to know what. By
putting the hashing on the client-side, you remove the requirement that
clients need to know what password is associated with the given hash
value. That weakens your security.

 

[Glenn]

Hi,

With regard to the password, I'd suggest an absolute minimum of six
characters. I prefer a minimum of eight characters. As Chris said,
the end users may want only six. Maximum? IMHO, twelve may be a good
practical limit. Not too many people are going to remember a
twelve-character or longer password ;-)

I personally like to stay away from the special characters, i.e. those
which are not letters or numbers.

Yoyoma's discussion about hashing the password and storing the hash in
the database is right on the money. I wrote a password-handling class
some time ago which does just that, using java.security.MessageDigest
and the SHA algorithm(MD5 can also be used). The password is hashed
and then stored in the database table. Upon login, the entered
password is hashed; the hash is compared to the stored hash in the
database and the result dictates where the application goes next.

Have fun,


- Glenn

 

[Sudsy]

Glenn wrote:

Yoyoma's discussion about hashing the password and storing the hash in
the database is right on the money. I wrote a password-handling class
some time ago which does just that, using java.security.MessageDigest
and the SHA algorithm(MD5 can also be used). The password is hashed
and then stored in the database table. Upon login, the entered
password is hashed; the hash is compared to the stored hash in the
database and the result dictates where the application goes next.

Those big wheels just keep on turning...
Check out how passwords are stored in *NIX systems. Interesting
historical precedents to boot. And it doesn't matter how long the
password is when the permutation engine only spits out 11 bytes...
(okay, 13 when you include the "salt")