13

At this moment I'm busy working on an webapp with a friend of mine. The main problem we have is that we are only allowed to generate 50 GB a month in datatraffic.

My question is: Does hashing the passwords for users (when creating accounts or logging in) negatively affect the maximum datatraffic per month? If so what are the alternatives to make sure the information about our users is safe?

11
  • 66
    always always always always always always hash passwords. if you have a password, hash it before you store it. Disregard any potential downsides to hashing user passwords, as the potential gain far outweights potential losses due to none/poorly hashed passwords, except for what i assume are relatively special circumstances i have yet to encounter.
    – James T
    Commented May 13, 2016 at 10:01
  • 14
    and always add a salt before hashing. The two actions of salting and hashing will always provide a reasonable level of security for your users. But to reiterate the point...always hash. Always.
    – adelphus
    Commented May 13, 2016 at 12:34
  • 4
    Note that if you are limited to 50 GB a month, you may need to take extra precautions: DDOS protection, resource optimization, external CDNs,... 50 GB a month is not much when looking at the internet. There are sites that generate that kind of traffic in one day, or even less.
    – Nzall
    Commented May 13, 2016 at 13:42
  • 24
    Unless the sole purpose of your webapp is to log in, the data traffic generated by the client credentials should be the least of your concerns. It's like trying to save on the water you drink while changing the water of your pool everyday. Commented May 13, 2016 at 13:44
  • 3
    You could just use google or even facebook authentication and not deal with logins and passwords yourself at all. Commented May 13, 2016 at 14:01

1 Answer 1

72

Yes, you should hash your passwords. Storing passwords in plaintext is not acceptable.

No, it does not affect the amount of traffic your site require. The hashing should be done server side, so it does not affect what is transmitted from the client.

Hashing the passwords protect them from theft once they are stored in your database. To protect them from theft when they are transmitted from the client to the server, you need to use HTTPS.

Some related reading:

12
  • 26
    Just a minor point to make it clear: Hashing passwords does not protect against theft (I can still steal the databases containing the hashes). Hashing ensures that the passwords cannot be obtained even when the database data containing the hashes is stolen.
    – adelphus
    Commented May 13, 2016 at 12:45
  • 2
    It would be like stealing a bunch of keys without knowing which locks they go to.
    – user82913
    Commented May 13, 2016 at 13:28
  • 8
    @nocomprende, not really. There's no physical key/lock analogy that really seems reasonable to me, because the hashed (salted) passwords are simply unusable.
    – Wildcard
    Commented May 13, 2016 at 14:09
  • 22
    It's like stealing the locks - you can tell if a key matches without being at the door, but you would need to create millions of keys to find a matching one.
    – Yogu
    Commented May 13, 2016 at 18:08
  • 5
    @Yogu More like making an exact copy of the lock without removing the lock from the door.
    – jpmc26
    Commented May 14, 2016 at 0:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .