Rule for specifying a user name

[AndrewMozley]

An application under development requires a user to have a Username to log in, and a Password.

The password is generally required to have a minimum length and should have a mix of alpha / numeric / mixed case / punctuation characters.

As far as the Username is concerned, is there a general practice followed by other system designers? Is any rule generally imposed? For example should a user name normally be only a mix of alpha and numeric characters - perhaps forced to upper case?

Thanks.

 

[Dan Freeman]

There is no general rule for either and it drives me nuts!

One website needs your email address as login, another makes you make up something that you have to remember.

 

[Tore Bleken]

A user name should be unique and easy to remember and have a minimum of characters, no other restrictions should be enforced. As for password, remember that you should NEVER store passwords, only a hash of the password. If someone forget their password, you send them a new one and ask them to change it to something they decide themselves asap.

 

[Mike Lewis]

I'd favour giving the usrs a free choice for their user name. Don't impose any restrictions, other than a maximum length. And don't make it case-sensitive. After all, it is a personal thing.

As far as passwords are concerned, I would disallow punctuation, especially commas, full stops, colons, semi-colons, single quotes, double quotes, "curly" quotes, etc. It's too easy to confuse these. At most, allow either hyphens or underscores (but not both).

I'm also against imposing a rule such as the password must have a mixture of letters, digits, upper case, lower case, etc. It seems obvious to me that imposing such restrictions actually makes the password less secure. But I won't bore you with my theory in that respect.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

There are all sorts of password 'rules' depending on the use of the password.

Yes, there are often (but not always) a requirement for both Upper & Lower case Characters combined with one or more Numeric character(s) and sometimes a 'special' character (example: "_", "#", "%", etc.)

And some usages require that the password be periodically changed at a fixed number of days (example: every 90 days)

You might want to first identify if there are 'rules' associated with the usage and type of data that must be followed and/or do you have Clients that have their own set of rules.
For example:
* Personally identifiable information (PII) data has its own rules
* And HIPAA Password Compliance has its own set of rules

And then other usages have NO required format for passwords.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

Funny how a question about username rules has more comments on passwords. So let me first say I dislike sites not allowing spaces in user names, why should a username only be one single word? What is so unusual about having a space or even some spaces in the username, eg using your real name? For example look at the user names of us.

In regard of passwords, what I hate about many sites is only allowing a small set of characters usable in passwords. Then you can't for example use password generators, that easily put a 200 character long password into the clipboard or even into the html form for you to set and later use without knowing it yourself.

On the other hand I like some advices about remembering a sentence and only using first letters of words, some punctuation and word lengths for digits. It's your decision to use whatever is on your keyboard and goes through. As tore points out what should be stored is a hash of the password anyway, a binary thing, not at all needing any capability to store some charset. The hash can even be shorter than what you're allowed to enter as password and that doesn't render longer passwords as unneccessarily oversized, the longer a password is, the more likely it leads to less frequent hashes than well known weak passwords do, so it highers the security of your stored hash even if a site does not salt your password or doesn't use other well known best practices. A password length limitation I would consider sensible is perhaps 1K size, that already makes each login submit a longer request than usual, but if a site only allows 10 char passwords it's quite likely the store it in a char(10) field, that's a bad idea.

As long as the same entered password goes over to the script hashing it for comparison with the stored hash results in the same hash for the same entered password everything is fine and there is no reason to restrict the password characters just because of the risc of mistyping it. On the other hand, for handing out password reset passwords to a user, you can limit yourself on a subset of characters, easier to retype. Especially if it doesn't come to you as text you can copy&paste but comes as SMS on a legacy phone with no internet connection, or is read to you via phone, so you really need to be able to type it in easily. You'll not allow this reset password to persist anyway, the first action a user should take after logging in with such a password reset password is change it to his own new password.

Again, more rules about passwords than username.

Some systems I support use a short user name, more like name initials. Some desktops systems simply use the windows account name and that is lastname+usually one letter of firstname, more to prevent double names. Of course an email address is fine because its known to be unique property (in the sense of ownership too) of the user, but it makes less sens in a system for a company, where everybodys mail adress ends in @company.com or similar.

Bye, Olaf.

PS: Mike raises a topic by saying you shouldn't make a user name case sensitive. Besides this also similar looking chars allow other users to mimic a user name and still be a separate user. This can be used to profit from a good reputation in eg bid systems like eBay. But it's a hard rule to disallow similiar looking names. Would you really disallow l because it looks similar to I or 0 as it looks like O? This is rather a problem of display of names than it is a problem to distinguish them internally, as you do so by a numeric USer ID or a GUID, like every datas PK. It's also rather a rule for procduct keys which are typed in from reading of a box or label than rules about user names.

 

[Mike Lewis]

I'm betting that this is going to be a very L-O-N-G thread.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[DSummZZZ]

My thought is to make user names as easy as possible for the user to remember. But I also think it depends a lot on how many users you're expecting to use the app. If it's a worldwide thing then duplicate user names start becoming an issue. So I can see the point of maybe using longer user names such as an email address.
If it's 10 people at local office, maybe shorter is better. I make my apps let people choose their own, but yes. They must be unique.
Passwords can be any keyboard character except a space.


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[AndrewMozley]

Thank you all.

Yes, it was purely a question about the username. It arose because my initial design had forced the username to be upper-case; but then I noticed that the framework that a kind friend had provided had a default password of mixed case and I fell to thinking if there were any rules. . . .

I take your point, Olaf, about discouraging those names which mimic those of established users (it doesn’t particularly seem to happen on this site). That is a slight case for saving a name as upper case (even though it may be allowed to be entered as mixed case on the login screen).

In fact the application under development is likely to have a small number of users, most of whom will know each other.

Andrew

 

[Dan Olsson]

Isn't all problems above solved by having username equal to email address?
And that also makes it easier to mail out a new password if necessary...

 

[strongm]

Here's GCHQ's current guidance on passwords . An executive summary would essentially be just don't go crazy: long passwords, multiple character sets, regular changing (all the regular advice for passwords) is a actually a waste of time. And some of the password advice in this thread is fundamentally wrong. 200 character machine generated passwords that you can cut'n'paste ...? Seriously? And longer passwords lead to less frequent hashes? Really? (sorry to pick on one particular post here, but it happened the be the longest one with, therefore, the most to have issue with)

 

[Olaf Doschke]

Strongm, do you know Keepass? It generates such passwords with ease. And sites not allowing them are hindering a better security of users making use of such tools.

The PDF you link to says this about such password managers:

Software password managers can help users by generating, storing and even inputting passwords when required. However, like any piece of security software, they are not impregnable and are an attractive target for attackers.

That's true, but you can make your own password safe as safe as you can while you can't rely on the safety of sites. Just look at todays posts and find a login code like

LOCATE FOR user.username = ALLTRIM(thisform.txtUsername.Value) AND user.password = thisform.text2.Value

It's easily spotted as storing your password as cleartext, if you can log in with just half your 200 char password, if it's stored truncated. And if I find such behaviour, I'm gone, as it's a sure sign they don't store a password hash, but the password itself truncated to some smaller portion of eg 12 chars. Besides you can log in without entering a password, just knowing a username, if EXACT is kept at it's default OFF.

Bye, Olaf.

 

[Mike Lewis]

Isn't all problems above solved by having username equal to email address?

I don't see why. Email addresses are usually longer than simple user names, and not necessarily easier to remember or to type. And you are assuming that every user has an email address. Not all employees will necessarily have a company email address, and they might not want to use a personal address for reasons of confidentiality.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

Hmmm would GCHQ have any vested interest in making cracking simpler for themselves?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[strongm]

>Strongm, do you know Keepass?

Very familiar, thanks.

>It generates such passwords with ease

So what? It isn't the ease of generating such passwords that I question. It was the size of the password and the requirement that password fields would have to support cut'n'paste.

And, on a slightly different note, such password stores make juicy targets (as the GCHQ document hints when it says that the practice of using password management software 'carries risks'). You are simply moving the attack vector. This may of course be a risk worth taking.

 

[Olaf Doschke]

>password fields would have to support cut'n'paste.
Indeed keepass browser plugins can autofill html forms (again your risc to decide), it's not necessarily cut'n'paste via clipboard only.

>password stores make juicy targets
Yes, what I quoted. I can keep the safe safer by eg using smartcard, a master password is not the only option to login into the keepass password store.

Bye, Olaf.

 

[strongm]

>I can keep the safe safer by eg using smartcard

Indeed. And that just makes the case that passwords are perhaps not the best form of security ... which is where I (and GCHQ) came in

 

[Olaf Doschke]

On the topic of similar user names:

A simple way to check for similar looks would be using a CHRTRAN expression to replace a family of characters with one placeholder for this family of characters, eg CHRTRAN(lower(name),"âáàa","aaaa") would convert all the variants of a with accents to the plain a. It's quite similar to how sorting of all these accents works in collations. That's easily extensible in one CHRTRAN() replacement, simply extend it with further accents and other similarities.

Don't misunderstand this as normalization of the entered user name, eg if a User decides for the Name 'Léo' he'll become Léo. If someone later wants to take 'Leo', then this is forbidden. If someone else regsiters as 'Lea' and later another user wants 'Léa', that is forbidden. So this doesn't rule out accents in user names, but first spelling choosen wins. An index on the expression helps to find already taken similar names fast.

It's less relevant for a small site with 7 users, but just illustrates how to avoid similar user names, if you'd make that a rule. By far not perfect.

Bye, Olaf.

 

[JRB-Bldr]

While there is a lot of good advice here, it all really comes down to How Sensitive Is Your Data and Access To It

Personally I don't really care about how Secure some of my logins are because on those sites and/or those applications the data there just isn't that big a deal - either to me or to the company. Example: MySpamGoesHere email accounts

But then again there are other logins that I want to be SECURE due to the nature of the data and/or information there - PII data, HIPPA data, Accounting data, meeting Client requirements, etc.

Maybe you first need to determine how secure this login procedure NEEDS to be.

Remember that REAL SECURE login credentials are generally somewhat of a hassle for the user.
They are supposed to be that way to minimize the likelihood of them being 'guessed at' and/or used by others.

It is one thing to put SECURE login credential requirements into an application because YOU want to do so and another to do so because they are NEEDED.

Good Luck
JRB-Bldr

 

[Dan Freeman]

Isn't all problems above solved by having username equal to email address?

Most people will use their work email addresses which will change when they change jobs.

I participated in a store rewards program for a while that drove me nuts. The login at the cash register was the phone number I used to create the account and that number changed shortly afterwards. Their customer service (I use the phrase loosely) had no mechanism for changing the phone number on the account so I always had to remember my old phone number. I'm actually a little glad that chain went out of business.