Authentication BEST PRACTICES The basics Simple authentication is
Authentication BEST PRACTICES
The basics Simple authentication is single factor e. g. Username/ ID and password ØUsers sign up for an account and establish the password ØThis is stored in a database ØBut how!? ØThe application keeps track of the validity of the users login ØBut how!? ØWhen the user starts a new ‘session’, they login again, and the system authenticates them ØBut how!?
Let’s talk about how (and how not) User Create Account Success Error Server ( Application) my. User. Name, password Ok Not ok (duplicate name, bad password, … DB Create Account Valid username ? Store user name, store HASH of password (maybe salted hash)
What just happened? Obvious things: Ø Make sure it’s not a duplicate username Ø Make sure the password complexity rules are followed Less obvious: Ø We never store the password as plain text (if the DB is hacked, your password is now stolen) Ø Use a hash (one-way transformation <not encryption, since it’s only one way>) to store an encoded representation of the password. Now it’s not so easy to steal!
Now what? User Login Success Error Server ( Application) my. User. Name, password matches Doesn’t match DB Does account exist? If so, now check password Hash the password Are the hashes the same? Retrieve hashed password for this user
What just happened? Critical difference: Ø We only compare the hash!! What else usually happens? Ø Not shown in the diagram, but: Ø Once logged in, there is usually a ‘session key’ created Ø This is typically a unique identifier that is provided to the user/ client side, and is now used as a token to provide access on subsequent actions Ø Don’t have to keep logging in! Ø Maintains security Ø Session Key token can be expired (think about your own experiences with this!) Moral of the story: Design your application for login AND your APIs using this approach!!
- Slides: 6