1

Please follow thread below in comments for further clarity if anyone else has the same question

I'm not very knowledgeable in web security setup. Is it reasonable to store a hashed username and password in a php file inside a variable?

For instance I have a login form, on submit it hashes the username and password into a cookie. Than matches the hashed cookie to the hashed variables on the sever to allow access.

These are also one way hashes.

NicholasByDesign
  • 781
  • 1
  • 11
  • 33
  • 2
    So in other words, you are using a hash as a plain text .. no, *not safe*. – user2864740 Sep 09 '15 at 21:34
  • So for instance of say flat files, what would be a preferred method to store a one way hashed username and password to the server? – NicholasByDesign Sep 09 '15 at 21:36
  • Like I said I'm not big into security – NicholasByDesign Sep 09 '15 at 21:37
  • 1
    So why are you storing a hashed password in a php file and in a cookie? What do you *think* this is accomplishing for you? What you need to be asking is "what's the right way to do X?" where X is your *real* goal. – developerwjk Sep 09 '15 at 21:38
  • I'll agree to that that's why I asked. So I was experimenting with the idea of flat file logins for a databaseless login – NicholasByDesign Sep 09 '15 at 21:39
  • The purpose of a hash is so you don't have to store the actual password. If you then begin using the hash as the actual password, its not a hash anymore: now it IS the password. – developerwjk Sep 09 '15 at 21:41
  • Ok so to be clear. Say password is "cat" and it gets turned in to hash gibberish to match the gibberish in the variable that won't work. The user is still entering plain text human readable words – NicholasByDesign Sep 09 '15 at 21:44
  • But you're putting it in a cookie, and you still haven't explained what that's for, other than to leak the password out to the whole internet. – developerwjk Sep 09 '15 at 21:45
  • So I was just using the cookie as a way to match the users input for login to the php variable containing the username and password on a php file. So theoretically username is john and password is cat. on submit it drops a cookie turning each into gibberish. Then if the cookie gibberish matches the php variable gibberish it allows access to a page. – NicholasByDesign Sep 09 '15 at 21:51
  • When you make a PHP session and put the userid in it, PHP automatically links the cookie and the session. You don't do that by leaking the user's private information. – developerwjk Sep 09 '15 at 21:54
  • Ok, I get that. Basically I was looking at some tuts. That were going over using cookie or session. As my user may return, I was trying to avoid relogging after a certain period of time. Which was the decision to go with cookie. I was just curious of the ramifications of it being hijacked in anyway. – NicholasByDesign Sep 09 '15 at 21:57
  • 2
    in addition to PHP's automatic handling of the session cookie, you might want to save the user-agent and ip in the session and double check subsequent request against that, and invalidate any session where one of these has changed between requests, in order to prevent session hijacking (i.e. people stealing cookies and reusing them). Your approach actually enables me to steal someone's cookie and login as them rather than preventing it. Its backwards. – developerwjk Sep 09 '15 at 21:57
  • for extended login for days, you'd replace the session with a db in the comment above basically, and generate your own unique token to link a cookie to the db record. Extended logins are not really secure, but doing it that way is better than sending out the user's password (in any form) via a cookie. – developerwjk Sep 09 '15 at 22:08
  • Ok, so aside from the cookie. What about storing the username and password inside a php variable that encrypted? Is this safe enough if I do not allow direct access? – NicholasByDesign Sep 09 '15 at 22:10
  • 1
    Oh yeah, you don't want a database. Well, extended login without a database, the worst idea ever. – developerwjk Sep 09 '15 at 22:11
  • Ok, thanks for all your input, if you want to formulate an answer I'll accept it. – NicholasByDesign Sep 09 '15 at 22:14
  • dupe: http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords?rq=1 –  Sep 09 '15 at 22:16

4 Answers4

4

The problem is not in storing the hash in PHP itself; although a database is generally recommended.

The problem is using the hash as a plain-text password/secret; this is no different than any plain-text password. If someone was able to view the PHP source code they would have the hash and thus 'password'. Remember, password hashes are not secrets even though they should generally be treated confidentially1.

Instead, accept the username/password as plain-text - although, do use SSL to encrypt the password over the connection - and verify this against the hash2. At no point is a hash from the user trusted - as it cannot be proved that it was generated from an actual secret.

Once the submitted username/password has been validated on the server against the stored hash then a session nonce is established; it is this unguessable per-session secret that is then used to re-validate/authorize the user each subsequent request3. This is 'automatically handled' in PHP when creating a new session.

See the "Do's and Don'ts" and "Don't write your own password checker" answers, which are especially pertinent.

1 In real-world applications there should be a high priority given to confidentiality and preventing unauthorized disclosure. This is because most user choose stupidly short or common passwords (at least when given the chance) that can be brute-forced quickly. This can be mitigated by encouraging secure passphrase usage and secondary validators.

2 The newer password_verify / password_hash (or an equivalent library / backport) functions should be used as these correctly handles basic details including

  1. Applying a correctly generated salt which prevents rainbow table attacks, and

  2. Using an appropriate (ie. bcrypt) hash function which mitigates brute-force attacks on strong passwords/passphrases.

(If planning on using SHA - don't! - for hashing passwords, stop and read the links..)

3 Unlike using a hash-as-a-password this is only susceptible to session-hijacking, even if the hash in the PHP source code were leaked: it is also unique per-session. The attacker needs access to the client's cookies (via local access or Cross-site scripting (XSS); XSS can be mitigated with HTTP-Only cookies) or a method of intercepting the HTTP request (which can be mitigated with HTTPS); then, within that session, an attacker could impersonate the authenticated client.

As a long aside: if there was a need to store data in cookie (or otherwise sent back with a server request) and to ensure that it came from the server to begin with, one solution would be to use an HMAC as an authentication code. But this does not apply here.

Community
  • 1
  • 1
user2864740
  • 60,010
  • 15
  • 145
  • 220
2

User name/password authentication has a well tested solution that should not be modified.

When you store a password, use PHP's password_hash function. 

password_hash("rasmuslerdorf", PASSWORD_DEFAULT)

is a typical use case. This creates what people loosely refer to as a hash. It's not really a hash as it uses bcrypt, a key derivation function, but everyone refers to them as hashes. Store the password alongside the username. You can do this in a database or a flat file. You should do your best to keep this secure to prevent offline attack, but this hash is relatively secure against all but a very determined and well equipped attacker.

When the use logs in, pass their username and their clear text password to the server. The server should obtain the user's stored password hash using the username as the key. Then the server validates the password using PHP's password_verify.

Neil Smithline
  • 1,526
  • 9
  • 21
  • The term "hash" is a good (maybe even 'solid') choice - regardless of the slight technicalities - as it represents an irreversible one-way transformation. – user2864740 Sep 09 '15 at 22:29
1

All you've done here is substitute one password for another password. It is vulnerable to replay attacks. And that you are storing the effective password in a cookie opens up a world of exploits.

There are lots of good tutorials on PHP authentication on the internet, and a few bad ones. You should:

  • Use PHP sessions (with a session cookie)

  • Use https (and HSTS)

  • Send the submitted values serverside in a post for validation

  • On the server lookup the hashed password and random salt stored against the username

  • Hash the submitted password with the stored salt

  • If it matches the stored hash you have a successful authentication; regenerate the session id and continue.

  • Otherwise track and limit the number of failed attempts to prevent brute forcing.

  • provide an explicit logout function which removes the data in $_SESSION

symcbean
  • 47,736
  • 6
  • 59
  • 94
0

Not enough but it's good as start.

Cookies still a security problem as it can be used in attacks since the hash is stable result whatever it was MD5 or whatever.

In Wordpress they use a good strategy which is "Salt Keys" this makes application secure and hard to get cracked

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Creative87
  • 125
  • 9