0

Right off the bat, I'd like to know if there is a widely used library or standard that I could adopt to replace my "custom" scheme. I am certain that I, as one person, cannot produce something better than a community produced library.

That said, I am a security novice, and while reviewing other implementations did not find one that seemed to suit my exact needs. It was probably right under my nose and I didn't understand it.

I am developing a restful api and a javascript client. I intend to honestly implement rest and go stateless, meaning no server side sessions. All the information to answer any request must be passed by client to the server as part of the request.

The security solution needs to provide protection against a third party remote attacker that is moderately to seriously resolute.

I do not intend to protect against an attacker that is in physical custody of either the client or server systems.

So, with all that in mind, here is my custom :( solution.

  • Site-wide HTTPS
  • At registration to the service, the user's password is passed 'clear' to the server where it is stored in a salted sha-3 hash.
  • Upon login, the javascript client does not pass the user id and password to the server. Instead, it generates a random string and stores that in the window.name space. It then uses this string as a passphrase to perform 256bit AES encryption on the name and password, storing this cipher text in a cookie. This cookie has a life of 1 hour.
  • Henceforth, all API calls require that the client access the window.name string, decrypt the cookie, and pass the username/password 'clear' to the server. A unix-epoch timestamp is also passed.
  • The server, upon receiving any request, retrieves the user's salt, performs a sha-3 hash on the password, and compares it to the stored value in the db. It also ensures that the timestamp is within 60 seconds of the server time.
  • If those checks pass, the client is considered authenticated for that single request.

I'm definitely not a security expert, but I figure this forum is. Whatever you suggest I will take to heart.

11
  • SHA3 for hashing passwords is a big no no, have a look here cloud101.eu/blog/2013/09/14/about-secure-password-hashing Jan 2, 2014 at 16:48
  • Why do you say you're going stateless and don't use server-side sessions, then you create your own server-side session scheme, all you do differently is generate nonce on your own and pass it along in response body as well as response header (i.e. you split the session key in two parts)? You're contradicting yourself there. And you still pass user password in plaintext on each new request, so why not stick with that alone if you're using HTTPS? What specific threat vector are you looking to thwart against, because I don't see any benefit to your scheme, it only complicates it for you?
    – TildalWave
    Jan 2, 2014 at 16:49
  • @TildalWave I'm not sure how I'm creating a server side session? The nonce is generated on the client and passed to the server. I may be misunderstanding you. Sorry. And I definitely want to avoid complicating it for myself :)
    – user36581
    Jan 2, 2014 at 16:52
  • You're right, I misread one part. Still, I don't see how this added complexity adds anything to the security of your scheme. If client is required to keep the same browser window open he used to login, then what's the difference if you simply store his password directly in a JavaScript variable? Or use client storage? It would help if you tell us what attack vectors you were hoping to prevent with your scheme. You're still sending password after you decrypt it, so what's preventing some malicious script to collect it before the request is made?
    – TildalWave
    Jan 2, 2014 at 17:05
  • @TildalWave I guess I don't know how to answer the attack vector question cause I'm unsure what that is. I mean, I want the site to be hardened against replay attacks, impersonation, man-in-the-middle, XSS, and whatever else is important. ... About the javascript variable, I would do that but there's a page load after the login before accessing the application - unless I were to combine the pages. That's where the window.name comes in. Even then, it seemed a bit crude to store their password clear text in window.name, thus the encrypted cookie.
    – user36581
    Jan 2, 2014 at 17:10

1 Answer 1

1

Site-wide HTTPS

This is good.

At registration to the service, the user's password is passed 'clear' to the server where it is stored in a salted sha-3 hash.

This is bad. Hash passwords with a slow password hashing algorithm like pbkdf2, bcrypt or scrypt instead.

Upon login, the javascript client does not pass the user id and password to the server. Instead, it generates a random string and stores that in the window.name space. It then uses this string as a passphrase to perform 256bit AES encryption on the name and password, storing this cipher text in a cookie. This cookie has a life of 1 hour.

Henceforth, all API calls require that the client access the window.name string, decrypt the cookie, and pass the username/password 'clear' to the server. A unix-epoch timestamp is also passed.

The server, upon receiving any request, retrieves the user's salt, performs a sha-3 hash on the password, and compares it to the stored value in the db. It also ensures that the timestamp is within 60 seconds of the server time.

This looks overly complex to me. You can simply pass the username and password over HTTPS to the server during login. If the authentication succeeds, generate a random token on the server side and return it to the client. Any future request must include that token to be considered authenticated. You can invalidate the token after a certain period of time on the server side if needed.

4
  • Tho this requires tracking the tokens on the server side, which seemed to me to be a violation of a truly restful api. This solution is definitely easier tho.
    – user36581
    Jan 2, 2014 at 16:29
  • Also, passing hashed passwords mean that I would be revealing the type of hashing I use to protect passwords in my db, right?
    – user36581
    Jan 2, 2014 at 16:35
  • @user36581 No, why pass hashed passwords? Hash them on the server side.
    – user10211
    Jan 2, 2014 at 16:39
  • Ok, I misunderstood you. You were ok with passing the passwords clear, but you were recommending a different hashing algorithm. Ok, yeah totally cool. I'll hash on the server with one of the recommended algorithms.
    – user36581
    Jan 2, 2014 at 16:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .