6

I'm writing an API that hands out session id's using PHP's uniqid function (yes using more entropy). However I'm wondering if it adds more security to hash this id on the server, just like the passwords?

My thoughts:

Con

  • It's not really a secret that leaks to other sites, like passwords would.
  • If the database is compromised, all data is readable anyways. No need to take the API way.

Pro

  • The attacker can't read the value to send directly.
  • With salt the id's won't look the same in the database, even if they are.
Thomas
  • 163
  • 1
  • 7

3 Answers3

4

With salt the id's won't look the same in the database, even if they are.

  • Session tokens should be generated with a Cryptographically Secure random number generator.

  • The session tokens should have 72 bits of entropy or more.

For the foreseeable future, a 72-bit random token will be globally unique, so Salt is not necessary.

Pro [to hashing] The attacker can't read the [plain session token] to send directly.

  • It is best to check for a matching IP address in addition to session token. This may not work for mobile users because if their IP changes (i.e. weak signal) then they would be signed out.

Otherwise the attacker can use the session token from any IP, which, as you suggest, (after an SQLi attack) is little more than a convenience, because the attacker already has access to the full database.

However, hijacking a session in this way would be quite useful if some files/data are stored outside the database. (and if the compromised sessions have access to see that data)

[The session token] is not really a secret that leaks to other sites, like passwords would.

True.

If the database is compromised, all data is readable anyways. No need [for the attacker] to take the API way.

  1. Sometimes files or data are stored outside the database.

  2. A fairly common security procedure is to use separate database user accounts, so it is possible that the session tokens could be stolen with a read-only SQLi (i.e. limited access database user), with the most sensitive data remaining secure (i.e. requires special purpose database user)

  3. You may want to use passwords (and session tokens) to access encryption keys down the road.

It's really easy to run a quick SHA-2 on the session token, so if there's any chance that either #1, #2 or #3 will be implemented down the road, then go for it!

Community
  • 1
700 Software
  • 13,807
  • 3
  • 52
  • 82
  • If I limit the session token to an ip as you suggest I think there will be some practical problems: 1) Your sessions won't persist if you move to another ip like work or library 2) Now ipv6 is getting bigger, IPs will change all the time. Did I understand that correctly? – Thomas Sep 30 '16 at 21:58
  • Yes. IP address restriction is helpful from a security standpoint, but does pose a usability problem for Mobile users, and some obscure LAN environments. *"IPv6 ... IPs will change all the time"* I'm not sure about that one. – 700 Software Sep 30 '16 at 22:02
  • 1
    http://stackoverflow.com/questions/618301/binding-of-ip-address-with-session-id#comment-431215 altough it's just a comment. But still it could become normal practice for normal users their IP keeps changing as they have a lot of them then. – Thomas Sep 30 '16 at 22:06
  • 1
    Indeed the security benefit to requiring a matching IP address has very specific scope. (and you can ask a question to understand where the security benefits are strongest) As for whether this will negatively affect your user-base (and whether your service will see the IPv6 address at all) is something you can decide for your own project, and balance with the potential security risk and benefit. You can always take away the requirement later. – 700 Software Sep 30 '16 at 22:10
3

It is a good to have feature but not absolutely mandatory.
You would have a lot more to worry about if an attacker is able to leak data from your storage. If you are doing a good session management, you should not worry a lot about hashing the session key.

You can refer to the OWASP guide to session management: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
And another blog post:
https://hueniverse.com/2015/07/08/on-securing-web-session-ids/

Limit
  • 3,191
  • 1
  • 16
  • 35
1

Two attack vectors come to mind:

SQL injection-- either against your public site or an administrative management site -- May allow a malicious user to obtain a session ID in real time, meaning they could impersonate any user. See also this article

Log mechanism-- you site your be logging session events, and if those are logged with the cleartext session ID, and the access controls to the log files are not as secure as your database, then you will have the same problem. Link to OWASP guidance on this matter

John Wu
  • 9,101
  • 1
  • 28
  • 39
  • For SQL injection prevention I use PDO. About the cookie's lifecycle: I would like to make it somewhat long, gmail for example has a long experation time right? Is my currents setup ok? – Thomas Sep 30 '16 at 21:08
  • 1
    @Thomas you can always renew a session ID when it is expiring. No need to keep it long. – Limit Sep 30 '16 at 21:20
  • P.s. Should I limit the attemps because of this? – Thomas Sep 30 '16 at 21:48