-4

So I'm trying to do an autologin, so that then the user doesn't have to sign in every time. And In order to do that I'm generating a key, with 

sha1(uniqid($user, true)).md5(uniqid())

Now my question is, is this safe enough? It returns something like this 

53495c810be8f24f141e478ccd9732f895dc10f6c0fe68391c482012297935c4b30ab12b

Which looks pretty, pretty secure. But is it really? Any help would be great.

idris
  • 1,019
  • 1
  • 9
  • 22
  • The approach is insecure, and it has nothing to do with the has chosen. If you use such an "autologin" then you are *trusting* the previously-saved client data, it doesn't matter how random it looks. (Session cookies do use random numbers, but this is to persist within the session, not autologin.) – user2864740 Jul 25 '14 at 22:42
  • So you're saying to not to use an autologin? If its not safe why does nearly every site out there do it? @user2864740 – idris Jul 25 '14 at 22:44
  • 2
    No, most sites do *not* have "autologin". Most sites use cookies for sessions (which often contain a nonce and are persisted for a period of time). Most browsers support remembering passwords. Also, per the documenation of uniqid, it is not even suitable for a nonce: "This function does not create random nor unpredictable strings. This function must not be used for security purposes. Use a cryptographically secure random function/generator and cryptographically secure hash functions to create unpredictable secure IDs." – user2864740 Jul 25 '14 at 22:44
  • Well I'm generating the string for the cookie.... And I'm assuming i'm on the wrong track? @user2864740 – idris Jul 25 '14 at 22:47
  • 1
    PHP already supports adequate session support and takes care of the nonce generation automatically. See [start_session](http://php.net/manual/en/function.session-start.php), etc. – user2864740 Jul 25 '14 at 23:25
  • The only issue is when the browser is closed, the session ends. @user2864740 – idris Jul 25 '14 at 23:33
  • 1
    [PHP can be configured with a different session cookie_lifetime](http://stackoverflow.com/questions/520237/how-do-i-expire-a-php-session-after-30-minutes) - e.g. a day - such that the session won't end when the browser is closed (which is just the default behavior). Don't make up problems that don't [need to] exist. – user2864740 Jul 26 '14 at 00:16

1 Answers1

2

If you are using the generated value as a "key" which is sent to the browser as a cookie and also references data on the server which is never sent to the browser, then yes it somewhat secure but is overcomplicated. If this is the case, you do not need to include the username. Why not make the data entirely random every time? You could accomplish the same thing with:

sha1(uniqid())

This has better performance too since there is only one hashing algorithm at play. MD5 should not be used for anything, so I would use sha1 unless tight performance was required.

(Added in edit #1) If this is what you are doing, then when you store the authentication record in the database, you should keep track of what time it was created, and enforce that it will only live during a particular lifetime. Providing an "infinite authentication" mechanism is always insecure, and providing a time-limited authentication scheme is a hedge bet, one which we all use every day with the cookies in our browsers which expire over time on the server, so even if the value of the cookie becomes known to an attacker later, it is not possible to access the resources on the server beyond the intended time period.

If you are however attempting to store both a username and a password in a cookie as a hash, then that approach is highly insecure. If I am an attacker and I know the scheme at play, I can brute-force the hashes to produce the usernames and passwords involved. This takes time, but is quite feasible. It does not matter what kind of "combinations" of hashes you choose as the developer. In fact, the more you attempt to combine cryptographic solutions in the interest of making it "more secure" will likely reduce the security of your system.

William Lahti
  • 1,150
  • 11
  • 11
  • All I want to do is generate a key. Set it as a cookie. Store it in the database. Then when the user goes to the page if the cookie matches the key they'll be logged into the account the key is associated with. Secure enough? – idris Jul 25 '14 at 22:53
  • Cheers! I have added a section talking about the precautions that should be taken when creating long-term authentication tokens. Does that help? – William Lahti Jul 25 '14 at 23:02