User Authorization and Safety Practices in Ruby on Rails

Chapter 3.3 - User authorization & safety User authorization & safety Presented by: Maciej Mensfeld senior ruby developer@wordwatch.com senior ruby developer@furioustribe.com maciej@mensfeld.pl dev.mensfeld.pl github.com/mensfeld Maciej Mensfeld

Chapter 3.3 - User authorization & safety User authorization & safety Presented by: Maciej Mensfeld senior ruby developer@wordwatch.com senior ruby developer@furioustribe.com maciej@mensfeld.pl dev.mensfeld.pl github.com/mensfeld Maciej Mensfeld

Ruby on Rails: User authorization & safety User authorization & safety Please ask me to slow down, if I speak to quickly; ask me again, if I forget; ask questions, if anything i say is not clear; feel free to share your own observations Maciej Mensfeld

Chapter 3.3 - User authorization & safety Let s start with a naive approach! Password DB Login Password DB Login Maciej Mensfeld

Chapter 3.3 - User authorization & safety And let s do it! User model (or an update if already exist) rails g migration NAME login: string, null: false, unique: true password: string, null: false Maciej Mensfeld

Chapter 3.3 - User authorization & safety Quite good but What s wrong with this approach? Maciej Mensfeld

Chapter 3.3 - User authorization & safety But we don t have any data that Most of stolen data can be used somehow! Maciej Mensfeld

Chapter 3.3 - User authorization & safety Simple case study SHA + Salt @ Shippuuden.pl Maciej Mensfeld

Chapter 3.3 - User authorization & safety Simple case study You should not use MD5 You should not use MD5(MD5) Any Hash algorithm can be broken with bruteforce attack Any bruteforce attack can be faster with rainbow tables It is way easier when passwords are short :) md5(md5), sha2(sha2) Static vs dynamic salt Maciej Mensfeld

Chapter 3.3 - User authorization & safety Secure Salted Password Hashing Maciej Mensfeld

Chapter 3.3 - User authorization & safety Secure Salted Password Hashing Maciej Mensfeld

Chapter 3.3 - User authorization & safety What is a cryptographic hash? A cryptographic hash function is a deterministic procedure that takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that an accidental or intentional change to the data will change the hash value. The data to be encoded is often called the message, and the hash value is sometimes called the message digest or simply digest. 4e2ecff8f8be5a7d4d8821266d956d844aa5b8eebd5983edbaaa6fa7fc9bc9e21 de42d443f50d8608a79f6507b7e95c6d4a913615c85710f86a40bc23cdc5d5d Maciej Mensfeld

^(?=.*\d)(?=.*([a-z]|[A-Z]))([\x20-\x7E]){8,40}$ Chapter 3.3 - User authorization & safety Passwords should not be weak! When we store users passwords in our systems (databases, files, etc), they should be safe. If we get hacked and our database will get stolen, passwords should be protected. No one should be able to read them. Most users have one password for all their web-activities, so if this password get stolen, probably cracker will be able to log in into victim Facebook, Twitter and any other web accounts. But what about brute-force attacks? Any password should be validated before use. They should not be to short or two simple. We can do it by using regular expression: ^(?=.*\d)(?=.*([a-z]|[A-Z]))([\x20-\x7E]){8,40}$ Maciej Mensfeld

Chapter 3.3 - User authorization & safety Salt, salt, salt How tu generate and use salt? The easiest way is to use one, global salt. Example: As you can see above using salt will dramatically increase password power. One global salt has one major and really big disadvantage. If two users have same password they will also have same output hash. So, if we have a lot of users and some of them have same hashed password, we need to figure out only one hash and we will have access to accounts of the rest of users with same hash. We can also generate our own rainbow table dedicated for our cryptographic hash function and salt. Maciej Mensfeld

Chapter 3.3 - User authorization & safety Salt, salt, salt To protect against such behaviours we should use uniq per user salt. How to generate such salt? Combine some per user data and some random stuff. Example: We store salt with password hash. Don t worry it is safe. Since each user has his own uniq hash, there does not exist any general rainbow table. Mix password, dynamic and static salt and you will be safe. Furthermore, when mixing salts and password in a uniq way until cracker steals database and source codes, he will not know how to generate rainbow tables. Example: Maciej Mensfeld

Chapter 3.3 - User authorization & safety Let s implement! require digest/sha2 Password and password confirmation salt generator salt (persisted) hashed_password (persisted) What do we need? password checker Login hashed password generator Logout Maciej Mensfeld

Chapter 3.3 - User authorization & safety Spec for User model Put the test spec into test/units directory ruby -Itest ./test/units/user_test.rb Maciej Mensfeld

Ruby: User authorization & safety Live long and prosper! Presented by: Maciej Mensfeld maciej@mensfeld.pl dev.mensfeld.pl github.com/mensfeld Maciej Mensfeld