Unacceptable Login Name Characters

What are the generally stated unacceptable login name characters?

- hyphen
- asterisk
- comma
- whitespace in the middle
- aposthrophe

Have I missed any up above?

Would passwords have any unacceptable characters?

Dan Quayle
Tuesday, January 20, 2004

©«®Ç㶤÷ǔДКצع٣∫™€תּﭻﻳ ☻

?

www.MarkTAW.com
Tuesday, January 20, 2004

Hmmm most of those didn't show up.

www.MarkTAW.com
Tuesday, January 20, 2004

Either:

Only (a-z|A-Z|1-0)

Or:

No characters that have special meaning in your programming languages, like ( ) ; #

What you're looking for is to prevent hacking, not to prevent someone from using "my grandma and your grandma sitting by the fire" as a passphrase.

www.MarkTAW.com
Tuesday, January 20, 2004

Wouldn't using extremely weird characters like all the varieties of whitespace be the best chance of preventing a brute force attack?

Dennis Atkins
Tuesday, January 20, 2004

Whitespace has varieties?

I once read about someone cybersquatting on something like:

Microsoft.com

where the M is actually the Greek letter Mu (U+039C).

They could send you e-mail and actually direct you to their site and it would look exactly like you were on Microsoft's site.

www.MarkTAW.com
Tuesday, January 20, 2004

What's the reason for forbidding any characters?

> No characters that have special meaning in your programming languages, like ( ) ; #

Having escape characters in string variables only matters if you're calling something like eval.  But it's probably better to do it right than by forbidding random characters.  The user really doesn't care what language you don't understand well enough to keep from screwing up.

Brian
Tuesday, January 20, 2004

I don't see why any characters should be considered "unacceptable" in either the login name or the password.

There is the possibility of SQL Injection or embedded HTML/JavaScript attacks, but if you're silly enough to do something like that, you really shouldn't be doing the job.

I like the idea of hashing (SHA1) the Username and Password on the client side, before it gets sent to the server. So the raw uid/pwd never get sent across the wire. There's no need to obfiscate the fact that it uses SHA1 as it is "computationally infeasible" to reverse (ignoring entropy issues).

Steve Jones (UK)
Tuesday, January 20, 2004

And it is also useless to hash on the client and send the hash, because then it becomes enough to capture the hashes to gain access... 
Use SSL and send the user name and password as is.

Tal Rotbart
Tuesday, January 20, 2004

I neglected to mention the SSL as well as hashing, which you would use too.

Steve Jones (UK)
Tuesday, January 20, 2004

I agree with MarkTAW, only use alpha-numeric characters as this is the norm that people expect. The exception to this is when you use an email address as the login ID. I would encourage this as this is the easiest thing to remember for a user. Of course, this may not apply.

m
Tuesday, January 20, 2004

alphanumeric and _ for usernames, and allow anything for passwords.

Though, don't get caught with the error that Oracle has in some versions of SQL*Plus, where you can't have '@' in your passwords.  The reason is that to start it from the command line, you use this command:

sqlplus username/password@database

well, if you have an @ in your password, it gets the database name mixed up.  Even when you don't start it from the command line.  It will give you an error that the database doesn't exist.  very frustrating to fix.

Andrew Hurst
Tuesday, January 20, 2004

If your system generates the password, rather than asking the user to create it, you might want to exclude the number one and lowercase L, as they tend to look the same in some typefaces: 1l

Mark S.
Wednesday, January 21, 2004

  Recent Topics

  Fog Creek Home