2 replaced http://stackoverflow.com/ with https://stackoverflow.com/
source | link

Good ideas are time-bounded.

Protecting passwords by MD5'ing them was once a good idea. Then rainbow tables and MD5 collisions were discovered. So now it is a bad idea.

Sending plain-text passwords over HTTP is a very bad idea, sending plain-text passwords over HTTPS is a very good idea by comparison, but there are still better approaches you can take.

Memory - As a general guide, you must assume that the server you are sending your credentials to is secure, so don't worry too much about plaintext passwords being held in memory unless you're looking to develop ultra-secure applications.

Logs - Logs generally do not contain any HTTP POST/UPDATE data, because that data is potentially very sensitive - and sometimes to store it in unencrypted log files would be illegal - such as when a client submits credit card details for processing a payment.

Passwords should only be sent as part of the HTTP request body, never in the URL for the site, and preferably not in HTTP headers either. BASIC HTTP authentication uses a password field in the header, primitively protected with Base64 - but this is only to prevent people shoulder-surfing the password, it won't protect it from anything else.

You could look at Client Side Password HashingClient Side Password Hashing, which would involve hashing the password on the client side before it is sent to the server - thus even the server would never have the real password text (and should still further salt and hash it anyway), but this is more complicated to setup and is not recommended for anyone who doesn't fully understand what they're doing.

Good ideas are time-bounded.

Protecting passwords by MD5'ing them was once a good idea. Then rainbow tables and MD5 collisions were discovered. So now it is a bad idea.

Sending plain-text passwords over HTTP is a very bad idea, sending plain-text passwords over HTTPS is a very good idea by comparison, but there are still better approaches you can take.

Memory - As a general guide, you must assume that the server you are sending your credentials to is secure, so don't worry too much about plaintext passwords being held in memory unless you're looking to develop ultra-secure applications.

Logs - Logs generally do not contain any HTTP POST/UPDATE data, because that data is potentially very sensitive - and sometimes to store it in unencrypted log files would be illegal - such as when a client submits credit card details for processing a payment.

Passwords should only be sent as part of the HTTP request body, never in the URL for the site, and preferably not in HTTP headers either. BASIC HTTP authentication uses a password field in the header, primitively protected with Base64 - but this is only to prevent people shoulder-surfing the password, it won't protect it from anything else.

You could look at Client Side Password Hashing, which would involve hashing the password on the client side before it is sent to the server - thus even the server would never have the real password text (and should still further salt and hash it anyway), but this is more complicated to setup and is not recommended for anyone who doesn't fully understand what they're doing.

Good ideas are time-bounded.

Protecting passwords by MD5'ing them was once a good idea. Then rainbow tables and MD5 collisions were discovered. So now it is a bad idea.

Sending plain-text passwords over HTTP is a very bad idea, sending plain-text passwords over HTTPS is a very good idea by comparison, but there are still better approaches you can take.

Memory - As a general guide, you must assume that the server you are sending your credentials to is secure, so don't worry too much about plaintext passwords being held in memory unless you're looking to develop ultra-secure applications.

Logs - Logs generally do not contain any HTTP POST/UPDATE data, because that data is potentially very sensitive - and sometimes to store it in unencrypted log files would be illegal - such as when a client submits credit card details for processing a payment.

Passwords should only be sent as part of the HTTP request body, never in the URL for the site, and preferably not in HTTP headers either. BASIC HTTP authentication uses a password field in the header, primitively protected with Base64 - but this is only to prevent people shoulder-surfing the password, it won't protect it from anything else.

You could look at Client Side Password Hashing, which would involve hashing the password on the client side before it is sent to the server - thus even the server would never have the real password text (and should still further salt and hash it anyway), but this is more complicated to setup and is not recommended for anyone who doesn't fully understand what they're doing.

1
source | link

Good ideas are time-bounded.

Protecting passwords by MD5'ing them was once a good idea. Then rainbow tables and MD5 collisions were discovered. So now it is a bad idea.

Sending plain-text passwords over HTTP is a very bad idea, sending plain-text passwords over HTTPS is a very good idea by comparison, but there are still better approaches you can take.

Memory - As a general guide, you must assume that the server you are sending your credentials to is secure, so don't worry too much about plaintext passwords being held in memory unless you're looking to develop ultra-secure applications.

Logs - Logs generally do not contain any HTTP POST/UPDATE data, because that data is potentially very sensitive - and sometimes to store it in unencrypted log files would be illegal - such as when a client submits credit card details for processing a payment.

Passwords should only be sent as part of the HTTP request body, never in the URL for the site, and preferably not in HTTP headers either. BASIC HTTP authentication uses a password field in the header, primitively protected with Base64 - but this is only to prevent people shoulder-surfing the password, it won't protect it from anything else.

You could look at Client Side Password Hashing, which would involve hashing the password on the client side before it is sent to the server - thus even the server would never have the real password text (and should still further salt and hash it anyway), but this is more complicated to setup and is not recommended for anyone who doesn't fully understand what they're doing.