we're in process of migrating our mvc-based server application , making rest-ful api through calls handled.
i've been reading on aes encryption , oauth2 , decided implement solution grown form concepts follows:
- client sends request log in providing userid or email. request hmac'd using api secret key.
- the server checks if userid/email matches existing account , if finds one, creates , stores server nonce sends part of response client.
- the client creates own client nonce , creates new temporary key api secret key , both nonces. sends login request password encrypted using temporary key [for added entropy , avoid ever sending password in plaintext].
- the server decrypts password , hmac using latest nonce has stored client on platform [a mobile , web client can have own distinct nonces , sessions] , client nonce sent in clear, if hmac checks out validates password against database [pbkdf2 hashing , salting].
- if request valid , password , userid match records, new session secret key created userid on platform , secret key sent client , used hmac every api request fromt hat client henceforth.
- any new non-login request include hmac signature computed session secret key , randomized iv's.
all communication handled through tls added security , not line of defense.
on mobile apps work since can hide mobile app's secret key on config file , gives decent measure of security - [perhaps not lot i'm not sure] if try convert requests our webpage form mean using javascript handle client-side aes encryption , authentication , ... well article explains, " if store api key in javascript web app might print out in big bold letters across homepage whole world has access through browser’s dev tools."
i use nonces api secret key -- or forgo using aes encryption requests altogether , try validate through other means such csrf tokens , making sure requests come form our own front end in way - wouldn't work if wanted create api allows integration other pages or services , then, how go securing client's secret session key?
the article suggests generating single-use cookies tokens that's limited solution works poster's services wouldn't us. want able hmac every request user sends user-specific key can expire , reset , since service handle money, want request authentication locked down tight.
so options?
do ditch javascript since is doomed? there way store secret key without exposing clear day hardcoded .js script? should generate new temporary secret key used login calls , send user when request server nonce?
also, post linked first suggests using cookie store session key client , access key js. ok or provide more holes seals?
it's know measures prevent security holes.
you correct javascript not suited encryption because there no place store secret. there no encryption libraries because shouldn't doing encryption in javascript.
the session key can serve authentication key. if you're using tls connection secure , attacker can't know session key. additionally, javascript doesn't need know session key. cookies, default, sent every request. , can set cookie http-only cookie. don't have to this, add layer of security.
you can give session cookie long expiration time works secret api key. browser take care of storing cookie securely. advised rotate session key often, typically @ start of every new session , when authentication information changes (like password reset).
csrf-tokens prevent replay attacks. it's recommend secure modification request csrf-token. don't need csrf-check every request, requests modify sensitive information (such login credentials, or in case: transactions). csrf-tokens can use same approach session key: store in cookie.
the key part javascript doesn't need know of this.
one important thing i'm sure realize keys or nonces generate must cryptographically safe. don't use low entropy functions.
so:
you don't need encrypt userid or email, tls already. additionally can send password well, don't need send separately in step 3. we're not going encryption in javascript. encryption handled tls/https alone.
if have separate authentication server (like single sign on), approach fine. else can skip step.
you don't need this.
the server doesn't need decrypt anything, encryption handled tls. how store password topic on it's own think you've got it.
ok. again, client shouldn't encrypt anything.
send session key. it's enough.
revised is:
client sends login credentials. connection must secure.
server verifies credentials , sends authentication token cookie , keeps track of authentication token session list.
for every request:
client includes authentication token. happens automatically if use cookies.
server verifies authentication token , possibly generates fresh token client use on.
Comments
Post a Comment