7 replies to this topic

[HiRo]

Hello, I am wondering if I have a form in html, which sends information like username, password, ID. It then sends that file to a php file, which processes on that data. On that point I encrypt the password. However, is this really safe? I wouldn't assume it to be so, since it looks like it's sending the data over to the .php file in which the information could get read as pure text before it reaches the .php file. If it isn't, what's the alternative solution.

Thanks,
HiRo.

(I accidentally posted this on the php tutorial section :( sorry.)

[Orjan]

One alternative is to encrypt the password upon sending with javascript. it's not very safe either, as ppl can read your code on how you do, but the sending itself would be some safer. (it's not pure text at least...)

[Alexander]

The only real security solution would be to use SSL, as any plaintext sent from computer A to server B can be read in plaintext otherwise.

[SoN9ne]

An example of what I do for my login systems:

• I use the onsubmit to call a JS method to hash the user's password with their username and a unique random salt that is generated and saved to the session for verification. (this will semi-protect the users password. It can still be deciphered but will take some work)
  
  
• I verify the hash with the salt in the session before I attempt a login.
  
  
• I then query the db using the username to retrieve the user specific salt (regenerated every successful login) and their password hash. I use a different Hash algorithm for passwords stored in the db. (the trick here is to store the hash with the proper salt and hashing standard to be used throughout the script.) I use the same unique salt from the form to verify the password when validating the hash to ensure the hash is the same.
  
  
• I then clear the session vars used and regenerate the session ID and delete the old session file to protect the session.

This is very similar to what I do. I have a few other steps I perform but this is the main concept of my login systems. I try to protect the user's password as best as I can but even hashing it with JS is not that secure since it can easily be deciphered but I'd rather make hackers go through the extra step.

[bbqroast]

If you want to stop the code being read as it goes USER --------> PHP then you need to use public key encryption.
Its reasonably complex but i'm sure you'll work it out (eventually).
Even if the user has the encrypting key (which is handed out freely) they can't unencrypt the message and vica versa.

[Alexander]

bbqroast said:

If you want to stop the code being read as it goes USER --------> PHP then you need to use public key encryption.
Its reasonably complex but i'm sure you'll work it out (eventually).
Even if the user has the encrypting key (which is handed out freely) they can't unencrypt the message and vica versa.

GPG over HTTP?

[BlaineSch]

SoN9ne said:

An example of what I do for my login systems:

• I use the onsubmit to call a JS method to hash the user's password with their username and a unique random salt that is generated and saved to the session for verification. (this will semi-protect the users password. It can still be deciphered but will take some work)
  
• I verify the hash with the salt in the session before I attempt a login.
  
• I then query the db using the username to retrieve the user specific salt (regenerated every successful login) and their password hash. I use a different Hash algorithm for passwords stored in the db. (the trick here is to store the hash with the proper salt and hashing standard to be used throughout the script.) I use the same unique salt from the form to verify the password when validating the hash to ensure the hash is the same.
  
• I then clear the session vars used and regenerate the session ID and delete the old session file to protect the session.

This is very similar to what I do. I have a few other steps I perform but this is the main concept of my login systems. I try to protect the user's password as best as I can but even hashing it with JS is not that secure since it can easily be deciphered but I'd rather make hackers go through the extra step.

Not everybody has JS enabled.

[Alexander]

Quote

Not everybody has JS enabled.

Agreed. Sacrificing any small form of user accessability for "one extra step to hack" is foolish IMO. SSL requires no code changes.