Send the link below via email or IMCopy
Present to your audienceStart 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
Username/Password Best Practices
Transcript of Username/Password Best Practices
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
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, Monster.com, Gawker, ADP, Scribd, Wordpress,
and too many others...
The process and/or means of confirming a person's identity.
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
ghash.io 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:
1024+ chars long
"You worry about the user giving you enough password. Let them worry about giving you too much."
These slides are at:
password = 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
password + a 30-char salt =