The Internet belongs to everyone. Let’s keep it that way.

Protect Net Neutrality
Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Username/Password Best Practices

No description

Ian Maddox

on 9 July 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Username/Password Best Practices

User Identification
What is your site's purpose?
Is the ID part of the user's public profile?
Is there a reason for the ID to be secret?
What technical limitations do you have?
"What you know" type authentication
Rules and consequences must be contextually-appropriate
Always follow best practices for password handling
More Reading
Raspberries To
eBay, Target, ShareBuilder, Adobe, AOL, LivingSocial, Evernote, Apple, Sony, Zappos, Blizzard, CDCSS, Citigroup, ING, AmEx, Chase, IBM, Sega, Steam, Stratford, Oregon DMV, NHS, INS, Drupal, AT&T, Heartland, Network Solutions,, Gawker, ADP, Scribd, Wordpress,
and too many others...
The process and/or means of confirming a person's identity.
Best Practices

Ian Maddox
Seattle PHP User Group
July 8, 2014
Are you Twitter or Chase?
If the users have a choice, be reasonable
Consider edge cases and username availability
Don't be Overly Generous
Consider your storage and transport
Your site design
And your character encoding capabilities
Bad Username Rules
Minimum length of 7 or more chars
Required mix of numbers and letters
Enforcing case rules
Good Username Rules
Don't allow leading/trailing space
Block hidden characters
No usernames so long they break the UI
Restrict characters that will confuse or cause unreasonable technical problems
Hash, Salt, Sleep Well
Rainbow tables are cheap. Losing all your customer data is not.
Are you Twitter or Chase?
Password rules should be a reflection of data value
Oppressive PW rules lead to Post-its
Proper Password Handling
Treat passwords like radioactive waste
NEVER EVER store a password in a cookie
You should not care how long a password is
Just use PHP's password_*() functions
Don't Store Passwords!
Unless you're PCI or SOX compliant, and even then... just don't.
Compare hashes, not passwords
"You should not have the ability to tell a user their password, much less offer that functionality via email or web."
What's in a character?
Web brute-force cracking at 1,000 per-second
Let's go nuts is crunching 46.31ph/s
AKA 46,310,000,000,000,000 SHA-256 hashes per second
At this rate, a 15 char pass could last...
Let Them Go Nuts
Since you're not storing passwords anyway, let them go bananas:
Special chars
1024+ chars long
"You worry about the user giving you enough password. Let them worry about giving you too much."
3,217 years
Maybe even:
Control characters
These slides are at:
On Hashes...
password = 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8

password + a 30-char salt =
Full transcript