It's definitely recommend to secure a modification request with a CSRF-token. It is advised to rotate the session key often, typically at the start of every new session and when authentication information changes (like a password reset).ĬSRF-tokens prevent replay attacks. The browser will take care of storing the cookie securely. You can give the session cookie a very long expiration time so that it essentially works like a secret API key. You don't have to do this, but it does add another layer of security. And you can set the cookie to be an http-only cookie. Cookies, by default, are sent with every request. If you're using TLS your connection is secure and an attacker can't know the session key.Īdditionally, JavaScript doesn't need to know the session key. The session key can serve as the authentication key. There are also no good encryption libraries because you shouldn't be doing encryption in JavaScript. You are correct that JavaScript is not well suited for encryption because there is no place to store a secret. It's good to know which measures prevent which security holes. Is this ok or would that provide more holes than it seals? js script? Should I generate a new temporary Secret key to be used for login calls only and send that to the user when they request the server nonce?Īlso, the post I linked to first suggests using a cookie to store the Session key for the client and then access the key from JS. I want to be able to HMAC every request the user sends with a user-specific key that can expire and be reset and since the service will eventually handle money, I want request authentication to be locked down tight.ĭo I just ditch Javascript since it is doomed? Is there some way to store a secret key without exposing it clear as day hardcoded into the. The article suggests generating single-use cookies as a tokens but that's a limited solution that works for the poster's services but wouldn't for us. I could use only the nonces as the API Secret key - or forgo using AES encryption for those requests altogether and try to validate through other means such as CSRF tokens and making sure all the requests come form our own front end in some way - but this wouldn't work if we wanted to create an API that allows integration with other pages or services and even then, how would I go about securing the client's secret Session key? well as this article clearly explains, " if you store your API key in a JavaScript web app you might as well just print it out in big bold letters across the homepage as the whole world now has access to it through their browser’s dev tools." On the mobile apps this would work since you can hide the Mobile App's Secret Key on a config file and this gives some decent measure of security - but if we try to convert all the requests from our webpage to this form this would mean using Javascript to handle the client-side AES encryption and authentication and. Any new non-login request would include an HMAC signature computed from the Session Secret key and randomized IV's.Īll communication is handled through TLS so this is added security and not the only line of defense.If the request is valid and the password and UserID match records, a new Session Secret Key is created for that UserID on that platform and this Secret key is sent to the client and will be used to HMAC every API request fromt hat client henceforth.The server decrypts the password and HMAC using the latest nonce it has stored for this client on this platform and the client nonce which was sent in the clear, if the HMAC checks out it then validates the password against the database.It then sends a login request with a password encrypted using this temporary key. The client creates their own client nonce and creates a new temporary key from the API Secret key and both nonces.The server checks if the UserID/Email matches an existing account and if it finds one, creates and stores a server nonce which it sends as part of the response to the client.This request is HMAC'd using an API Secret Key.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |