• Like
User Credential handling in Web Applications done right
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

User Credential handling in Web Applications done right

  • 8,061 views
Published

In my work I often see very bad practices how the users' passwords are treated in web applications. This is a short summary of the current state of the art, how to do it the right way.

In my work I often see very bad practices how the users' passwords are treated in web applications. This is a short summary of the current state of the art, how to do it the right way.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
8,061
On SlideShare
0
From Embeds
0
Number of Embeds
12

Actions

Shares
Downloads
23
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. User Credential handling in Web Applications done right Benjamin Erhart be@benjaminerhart.com
  • 2. Often seen situations● Passwords are stored in cleartext (EEEEVIL!)● Passwords are stored as MD5 hash (slightly less evil, but not much...)● Passwords are sent as GET query parameters over unencrypted connections
  • 3. Why Care? Your mama will leak your databasehttps://www.youtube.com/watch?v=aPWN683KsqU Need rainbow tables?https://www.google.com/search?q=md5+5f4dcc3b5aa
  • 4. Rainbows, Brony? Cute!● Rainbow Tables are precalculated reverse lookup tables for hash digests.● Just ask Google for the easy ones.● Find more specialized tables on shady sites.● Calculate your own, while youre not mining for BitCoins.● Having the proper RT enables attackers to find your users passwords in minutes!
  • 5. So, now? The bare minimum for your everyday inhouse app:use Digest::SHA qw(sha256);sub authenticate { my ($self, $password) = @_; if ( $self->password_digest eq sha256( $self->salt . $self->system->salt . $password ) ) { return 1; } return 0;} Add salts to your users passwords! TWO OF THEM! And fuckin use state-of-the-art hashing algorithms!
  • 6. User Salt● Generated on password creation/update● Unique per user● Store with the user in the database (own column or within password digest column using some delimiter)● Use as much randomness as you can get! (Quick bet: UUIDs)● This effectively destroys attackers possibility of using a single rainbow table.
  • 7. System Salt● Generated once for your application● Lives outside the database (e.g. config file)● Destroys the attackers ability to brute-force the passwords easily, when they already have the database dump.
  • 8. For your brand new web 2.0 social app: KDF● Kraft Durch Freude?● Key Derivation Functions!● Hashing functions are designed to be fast.● We dont process passwords by the millions normally.● We dont need it fast!● KDFs are about doing it slowly, so to make it harder for the attacker to crack our passwords.
  • 9. (PB)KDF self-madesub kdf { my ($password, $salt, $algo, $iter) = @_; my $digest = $password; for (my $i = 0; $i < $iter; $i++) { $digest = $algo( $salt . $digest ); } return $digest;}You can store the number of needed iterations with the user.Vary, if you want, but use many! (>1000)Should I mention that? Use standard KDF libraries of yourlanguage of choice!
  • 10. Transmitting Passwords● We aint gonna transmit passwords in the clear in 2012!● Bring yourself up to speed, how to configure your environment for SSL/TLS! Use CAcert for inhouse apps. (I can assure you, if you want.)● StartSSL issues free certs which most browsers recognize without warning.
  • 11. Transmitting Passwords contd● If SSL is really too much effort:● Do not use credentials in GET queries, these get stored in HTTP server logs, which will leak!● At least, use HTTP digest authentication, which doesnt transmit the users password.● Or use a JavaScript Challenge-Response Authentication (but be really careful about that!)
  • 12. Transmitting Passwords contd● If SSL is really too much effort:● Do not use credentials in GET queries, these get stored in HTTP server logs, which will leak!● At least, use HTTP digest authentication, which doesnt transmit the users password.● Or use a JavaScript Challenge-Response Authentication (but be really careful about that!)
  • 13. But I cant log in with other credentials for debugging now!● Thats really NOT a good reason to save passwords in the clear.● Add a feature which allows your admin users to impersonate any other user on the system!
  • 14. Password Strength● Educate your users● Show password strength meters in your change-password-forms● Disallow weak passwords (server side!!)
  • 15. Web Services● Do not use username/password credentials, especially, if you cant use encryption on transport.● Treating web services like users gives another attack vector. And theres always this one place, where you broke your authorization...● Treat them with different mechanisms, give out API keys for them, restrict them to IP adresses, domain names, time constraints...