Invariant Properties

  • rss
  • Home

Encrypt your usernames and email addresses!

Bear Giles | June 13, 2016

The possibility of a massive twitter password breach brings up a basic requirement in our world. I discussed encrypting personally identifiable information (PII) last August but didn’t mention login information specifically.

Encrypt your usernames and email addresses.

Use a unique, random salt/IV for each user.

This won’t stop a dedicated attacker with resources but it will slow them down and that buys time for you to discover the breach and for your users to change their passwords. Maybe not much time, maybe a week instead of a few days until a majority of passwords is cracked, but that could make a big difference for a lot of users.

How do I find a user if their username and email is encrypted?

This is easy to answer – also store a hash of each user’s username and email. Think HashMap – not unique identifier – it’s okay if there are a few users in each ‘bin’. In fact this is desirable since it makes the job of the attacker a little bit harder. You can use the last few bytes of a SHA hash.

You can efficiently determine the correct user – compute the password hash for each potential match using their unique hash salt. If there’s no matches you know it’s an invalid username and/or password. If there is you can encrypt the provided username or password, again using the unique salt (possibly different from the password hash salt) and see if there’s a match.

(Note: if you compare ciphertext you must make sure it does not contain the random salt/IV. Otherwise you’ll need to decrypt the values and compare the plaintext.)

Can I store a hash of the username or email address instead?

Good idea! The answer is maybe. It depends on your data model. That brings us to the next point…

Any other ideas to improve my security?

Think microservices. Even if you have a monolithic application you probably have it broken apart into separate components internally – e.g., an e-commerce site probably has user management and authentication, inventory, shopping cart, fulfillment, payment, etc. There’s no reason these components need to share the same database – they can use separate schemas and database accounts.

You can take that a step further and use different physical databases for critical information. E.g., the user authentication information can (and arguably should) be stored on a different server than anything user-facing.

If you do this then you can store a hash of the username and email address in your authentication tables and database. Again this will only slow down a dedicated attacker (they’ll have likely usernames and email addresses from prior attacks) but it buys you, and your users, time.

Another good idea is to periodically reencrypt everything with a new key. An attacker might not be able to obtain a copy of the database and the encryption key at the same time so this gives an extra measure of security. You might be tempted to use multiple encryption keys, e.g., one identified by the month they registered, but I doubt the improved security is worth the increased complexity. IMHO it’s much better to use a single key that you rotate on a regular basis.

I’m small fry – who would target me? Why should I bother with this?

You might be “small fry” but many of your users will use the same password on other sites. Attackers know this and that “small fry” often have lax security out of ignorance or the misguided belief that they’ll never be the target of an attack.

Comments
No Comments »
Categories
CEU, security
Comments rss Comments rss
Trackback Trackback

Archives

  • May 2020 (1)
  • March 2019 (1)
  • August 2018 (1)
  • May 2018 (1)
  • February 2018 (1)
  • November 2017 (4)
  • January 2017 (3)
  • June 2016 (1)
  • May 2016 (1)
  • April 2016 (2)
  • March 2016 (1)
  • February 2016 (3)
  • January 2016 (6)
  • December 2015 (2)
  • November 2015 (3)
  • October 2015 (2)
  • August 2015 (4)
  • July 2015 (2)
  • June 2015 (2)
  • January 2015 (1)
  • December 2014 (6)
  • October 2014 (1)
  • September 2014 (2)
  • August 2014 (1)
  • July 2014 (1)
  • June 2014 (2)
  • May 2014 (2)
  • April 2014 (1)
  • March 2014 (1)
  • February 2014 (3)
  • January 2014 (6)
  • December 2013 (13)
  • November 2013 (6)
  • October 2013 (3)
  • September 2013 (2)
  • August 2013 (5)
  • June 2013 (1)
  • May 2013 (2)
  • March 2013 (1)
  • November 2012 (1)
  • October 2012 (3)
  • September 2012 (2)
  • May 2012 (6)
  • January 2012 (2)
  • December 2011 (12)
  • July 2011 (1)
  • June 2011 (2)
  • May 2011 (5)
  • April 2011 (6)
  • March 2011 (4)
  • February 2011 (3)
  • October 2010 (6)
  • September 2010 (8)

Recent Posts

  • 8-bit Breadboard Computer: Good Encapsulation!
  • Where are all the posts?
  • Better Ad Blocking Through Pi-Hole and Local Caching
  • The difference between APIs and SPIs
  • Hadoop: User Impersonation with Kerberos Authentication

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

Pages

  • About Me
  • Notebook: Common XML Tasks
  • Notebook: Database/Webapp Security
  • Notebook: Development Tips

Syndication

Java Code Geeks

Know Your Rights

Support Bloggers' Rights
Demand Your dotRIGHTS

Security

  • Dark Reading
  • Krebs On Security Krebs On Security
  • Naked Security Naked Security
  • Schneier on Security Schneier on Security
  • TaoSecurity TaoSecurity

Politics

  • ACLU ACLU
  • EFF EFF

News

  • Ars technica Ars technica
  • Kevin Drum at Mother Jones Kevin Drum at Mother Jones
  • Raw Story Raw Story
  • Tech Dirt Tech Dirt
  • Vice Vice

Spam Blocked

53,313 spam blocked by Akismet
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox