Secure Authentication Best Practices
Learn about the best practices for secure authentication, including storing hashed passwords, avoiding duplicate usernames, and using session keys for enhanced security in your application design.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
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!?
Lets talk about how (and how not) User Server ( Application) DB myUserName, password Create Account Create Account Store user name, store HASH of password (maybe salted hash) Valid username ? Success Ok Not ok (duplicate name, bad password, Error
What just happened? Obvious things: Less obvious: Make sure it s not a duplicate username We never store the password as plain text (if the DB is hacked, your password is now stolen) Make sure the password complexity rules are followed 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 Server ( Application) DB Does account exist? If so, now check password myUserName, password Login Hash the password Success matches Retrieve hashed password for this user Are the hashes the same? Error Doesn t match
What just happened? Critical difference: What else usually happens? We only compare the hash!! 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 Login(id, pwd) Ok [session_key] Client Server Don t have to keep logging in! Maintains security Secure_function(ses sion_key) 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!!
Client Code (unit test) Server DB Login (userName, password Hash the password Note: username, password are secure information. NEVER put those params in the URL/ Query string! Get stored Hash of this users password Compare 2 hashes Success, Session_ley Stored session_key, expiration for THIS users session Prepare to use Authenticated API, add session_key to header create_new_user(session_key, ...) Extract session_key from header Get stored session_key of this user Valid Session Key? Yes, result of requested action Yes, Perform requested action No, authentication failure
How to handle session in http? Once you receive the session key Client: hdr = { session : 'sajdkeruidgs'}#add a session key - The client has to hold it, and provide it on each authenticated request In function calls, you would pass it as an argument In REST, you need to provide it as part of the HTML request result = post_rest_call(self, url, {}, hdr) //Other other verb Server: head = request.headers Best to place the key in the HTTP header Allows you to use any HTTP verb (GET, POST, PUT )
