emails as username - standards/best practice

[bchrist2]

what is the best practice and principles around using emails as username your web site. there is the principle that exists that people should not re-use the same username/password across websites.. but a large number of websites allow emails as usernames which would encourage the re-use of your username across websites.

ISO 27001 and NIst provide some guidance  . 

I would be interested to hear everyone's take and what approach they woudl recommend.

• ISO/IEC 27001 does not specifically address the use of email addresses as usernames, but it does provide guidance on the selection of usernames in general.
• The standard recommends that organizations should choose usernames that are not easy to guess, such as those based on personal information or easily obtainable data.
• ISO/IEC 27001 also recommends that usernames should be unique and non-reusable, meaning that they should not be shared or reused by different users or systems.
• This can help to prevent unauthorized access and reduce the risk of identity theft
• NIST's guidance suggests that email addresses can be a useful and secure choice for usernames, but that systems should provide flexibility and validation to ensure their effective use.
• Recommendation is that systems should allow users to choose a different username if they prefer not to use their email address.
• Additionally, NIST advises that systems should validate email addresses to ensure they are well-formed, but should not verify that the email address corresponds to an actual account or domain.

[JoePete]

---

@bchrist2 wrote:

what is the best practice and principles around using emails as username your web site.

---

Thanks for you doing the legwork of quoting the standards

I don't like using email as a username. It is too transient. We all change email providers, and at the same time, when I leave a company or a service provider, someone else with the same or similar name could end up with my old email address. In that context, email as a username doesn't work for ISO 27001

On the backend of things email as well as username have to be used by the system, meaning they can't be hashed. That said, it would be nice if they, and any other sensitive data (and what isn't these days?) were encrypted. If we are trying to do this robustly, we're encrypting both on the web/application side and the database side of things. That way, someone has to compromise both servers/hosts to get meaningful personal data.

That might seem overkill - it's just an email address right? But phishing remains remarkably effective and when you can add in other user data (address, phone number, etc.), it can be even more effective.

The not-easy-to-guess username standard I think misses the point. It might be effective against a brute-force attack on the login, but the far better approach is a lockout after X attempts. Plus, if it is hard to guess, it means hard to remember. So the system still needs an email address for each user (to email them their username). This doesn't really shift the risk. The likely attack is someone stealing the database  and then being able to key on email addresses, matching them to cracked passwords on other services (because people re-use passwords) or cracking the hashes they just stole. This returns to adding encryption on both the application and database.

That said, I've long encouraged people to not just use unique passwords for every service but also unique email addresses. Not only does that give you some buffer when a database gets stolen, but it also gives you a chance to track just what someone does with your email address as the spam starts to roll in.

So I think I went over my two cents with that response 😉 but this is a good question and I am curious what others see as good or best practice.

[Yuman]

@bchrist2 

Thanks for sharing.  You are right, for the username and email address, we are doing in our enterprise as below format:

email address: name.firstname@domain.com

username: nameXXX.firstname  while XXX replaced by 3 random digital.