1

I'm building web-app. And i have concern about security issues.

In world a lot of similar questions, but many of them does not have really clear answer(advise,suggestion). This is the reason why i made this question.

I have login page with username and password. User will POST them by HTTPS. Server will compare it with username and password from DB and if everything is ok, will generate access_token using some specific approach like: sha1(username + password + expiration_date), btw, expiration_date it's Unix time of expiration that token. In result expiration_date and access_token will be written into DB to related User record, access_token will be sent to client JavaScript app by HTTPS certainly.

Then all requests from client app will be made by HTTPS and access_token will be included into each header request. Server side should authorize this request, and detect User ID who had sent this request. Server will make search in DB by access_token and will check expiration_date). After access_token will be founded need to check next condition: current_date <= expiration_date, if true then ok, if false then we need to regenerate access_token using new expiration_date and save them to DB and send new access_token to client?

if Yes then what do you think about that approach form security side ?

Improve this question

1 Answer 1

Reset to default
1

Supposing you at least hash+salt the password of your users in the database, your workflow seems correct.

But I'd like to add two things :

  1. DON'T PUT THE USER'S PASSWORD IN THE TOKEN, it's not secure at all and totally useless. The expiration_date is also useless here. Just put a sha1(username + 'randomly generated string') and you will be good.
  2. If the expiration_date has expired, you shouldn't auto reauth the user, but ask her to log in again. Because if you do as you say, why use a expiration_date then?

For my #1, since your token is sha1(username+password+expiration_date), as an attacker, I can know the username, the expiration_date and the access_token, results of the sha1.

I only have to build a local brute force system that will try all the combination of the password possible, and compare sha1(username + "current testing password" + expiration_date) to the given access_token, and once I find it, I'll know the password :/

Improve this answer
6
  • and where is the third one ? you said you'd like to add three things :) Now about topic: point#1. This randomly generated string it should be regenerated every time after success login for each new session ? about #2 agreed. but it's not good for end users :( i need some possibility to prolongate their session.
    – web_dev
    Commented Jun 4, 2012 at 20:29
  • Oups, yeah sorry, the #1 contains two things (the password and the expiration_date, that I first splitted in two). The randomly generated string must be regenerated every time you create a new token, aka every successful login! Imagine it's a function generate_token(username) that will return the token, using the sha1(username + random string) technique. Now, for the #2, you can't prolongate their session, but you can extend the duration of the session
    – Cyril N.
    Commented Jun 5, 2012 at 8:06
  • what difference do you see between prolongate session and extend duration of the session ?
    – web_dev
    Commented Jun 6, 2012 at 13:00
  • Yeah sorry I wasn't clear. In your question, you wanted to update the expiry date in case the token is valid but the expire is old. This is not good because if I finally crack your token, I will be able to connect to an old session. Now what I suggest is to extend the expiry from, say, 2h to 1day.
    – Cyril N.
    Commented Jun 6, 2012 at 13:18
  • now I see, so "window" to crack it become narrow to one day ? let's resume it: to generate token better to use sha1(username + random::generateString()), and save result in DB. When request will come need to find the same access_token in DB and check expire date. If token expired redirect to login page. And all connection should be done by HTTPS. am I right ?
    – web_dev
    Commented Jun 7, 2012 at 5:10

You must log in to answer this question.

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