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?

Anders
  • 65,052
  • 24
  • 180
  • 218
Bomskie
  • 324
  • 2
  • 13
  • 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 May 13 '16 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 May 13 '16 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 May 13 '16 at 13:42
  • 23
    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. – Thibault D. May 13 '16 at 13:44
  • 3
    You could just use google or even facebook authentication and not deal with logins and passwords yourself at all. – Dean MacGregor May 13 '16 at 14:01
  • 3
    As others have stated, always both salt and hash passwords. Use a random salt for every password rather than a single salt for all of them. I like the bcrypt algorithm personally, but there are several with proven track records. – jpodwys May 13 '16 at 15:35
  • 2
    I wonder what kind of hosting you're using, since even cheap $5/month VPSs these days include 1TB of traffic per month. If that's your main problem, as you say, I'd switch to a more generous hosting company. – Martijn Heemels May 14 '16 at 13:44
  • 2
    @DeanMacGregor OpenId is better, because it's free, *secure*, open and Stack Exchange uses it. – wizzwizz4 May 14 '16 at 14:20
  • @wizzwizz4 according to this http://openid.net/get-an-openid/ a Google ID is an openID – Dean MacGregor May 14 '16 at 23:01
  • @DeanMacGregor But allowing *all* OpenId providers with one system is more useful than using each specific provider and missing some out. – wizzwizz4 May 15 '16 at 07:53
  • 1
    @wizzwizz4 you're right – Dean MacGregor May 15 '16 at 12:10

1 Answers1

73

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:

Community
  • 1
Anders
  • 65,052
  • 24
  • 180
  • 218
  • 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 May 13 '16 at 12:45
  • 2
    It would be like stealing a bunch of keys without knowing which locks they go to. –  May 13 '16 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 May 13 '16 at 14:09
  • @adelphus doesn't that mean that the passwords are indeed protected against theft? – Saturn May 13 '16 at 14:52
  • @Wildcard I suppose in a strict sense that is true. But when someone logs in, their attempt at the password is hashed and compared to the stored hashed password, correct? If I took a random key and put it in a lock, it would be the same situation. The key is "useless", it just happens to match the correct lock. What the key really means is that someone gave me access, it is a Token. It signifies a *prior arrangement* which is being verified. It doesn't actually "do anything". Passwords are similar, except that the system lets me choose my own. It is still a token of a prior arrangement. Right? –  May 13 '16 at 14:53
  • Even if it did increase the amount of data transfer... if difference between hitting your cap and not hitting your cap was logging in with a slightly higher data mount, you need to redesign your login system or you need to increase your data cap. – corsiKa May 13 '16 at 16:15
  • 1
    @nocomprende in order to log in, you need the _original password_, not the hash. Therefore you need to find something that works as a password for that hash - i.e. you need to carry out a pre-image attack. Any sensible hashing function should be resistant to pre-image attacks making this infeasible. – Boris the Spider May 13 '16 at 16:30
  • @BoristheSpider maybe we just need to find a different kind of token that represents the prior arrangement. A password is not that different than a "symbolon" (A piece of a reindeer antler that was broken in two) which is what was formerly used to verify that a courier was legitimate. If the courier was legitimate, you could trust whatever message he was carrying. We don't need to protect messages, we need a system of Trust. All interactions are ultimately based on trust. Without it, no system or society is possible. Put the effort there. –  May 13 '16 at 16:39
  • 1
    @nocomprende I don't understand the relevance of your comment. Sorry. I was saying that your analogy about locks and keys is wrong because a hash is entirely useless and cannot be used as a password. The danger with hashes lies in ones vulnerable to pre-image attacks - usually via rainbow tables due to a lack of salt. – Boris the Spider May 13 '16 at 16:48
  • 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 May 13 '16 at 18:08
  • 5
    @Yogu More like making an exact copy of the lock without removing the lock from the door. – jpmc26 May 14 '16 at 00:49
  • 1
    I think one important part is missing from this answer. If you add "with a salt value" to the first sentence, I think it would be a much better answer. – kasperd May 14 '16 at 06:52