24

Imagine the following situation. We're making a web application which should be really safe

Now the accounts/users are not directly added by us but they receive a letter with a logincode. We get a file every now and then containing an unsalted SHA-1 hash of this logincode, and some other really basic info.

Considering SHA-1 is now a days seen as a liability, and the software generating these hashes is not under our control (it's also probably old software not capable of better hashes)

Would it be a solution to hash the received hash using Bcrypt. This should fix the problem of it being unsafe/too fast if i'm correct? Should I also add a pepper?

Are there any other problems i might have missed? Or should we push back the problem and have them fix their software for better hashing functions?

Clarification:

Our client is an employee of a company and needs approval for this project.

The third party made a system for the company of our client that handles sensitive information about the customers of our clients company. They want to give some of their customers the ability to login to our application, this has to happen through their system because that's what the employees of our customer know and if they would have to add users manually in our application our client would not get approval.

Also if there is any leak or breach (even though technically we have 0 access to any sensitive information, even in our own application there is no name or any identifying info about the user) this could still attract unwanted negative attention that would hurt both the client and us.

Problem is, the system the third party made can only do unsalted SHA-1 Hashes. So my question is to try and see if we can work around this. Or if we are forced to tell my client to force the third party to implement a better hashing system, which they might just say answer with no we don't want to. Or it might cost a lot more money.

I hope i explained it a bit better while still being vague. :)

Jester
  • 663
  • 5
  • 10
  • 3
    You could potentially give more information, as it is not clear what either the third party or your company are using the SHA1 for. If you don't want the SHA1 at all for instance, just ask to have it not sent. If you are adding it to your own DB and using it to check plaintext passcodes sent by end user then Anders' answer applies. If the end user or third party instead is sending the SHA1 to authenticate, then some of Peteris' answer could apply - although you *could* store a bcrypt of the SHA1 at your end (and destroy the letter) in that case. – Neil Slater Nov 28 '16 at 14:27
  • 1
    @NeilSlater I understand your comment. I made it a bit vague on purpose as it's work related and don't feel it's professional to put the business idea of our client online. I'll try and clarify while trying not to do this. – Jester Nov 28 '16 at 15:03
  • @NeilSlater I added a clarification while still being as vague as possible. – Jester Nov 28 '16 at 15:19
  • Make sure to very strongly, very explicitly advise to your client that a SHA-1 hash in their system is dangerously weak and should be upgraded to modern password storage techniques. Also, this mechanism for delivering user data to your app is extremely ad hoc. It'd be better if storing user credentials wasn't even your app's responsibility (e.g., your app actually queries the other one to verify log in by obtaining a token or it implements OAuth or some other mechanism of getting the other app to perform the authentication). Then upgrading the other app doesn't have to be coordinated with you. – jpmc26 Nov 28 '16 at 18:41
  • @jpmc26 I did, and will continue to do so. But he has no direct influence on this. It's all a bit hard to explain without going into details that i don't want to mention. You're right that it would be better to move the responsibility to them but the system has no such options (it's old software that's used not just by their company, so third party making changes in it is highly unlikely.) This is because of the sensitivity of the data it is/was pretty much taboo anyway to link it to some other service. the only way he's alllowed to do it is by not sharing any sensitive data. – Jester Nov 28 '16 at 19:11
  • 1
    The problem isn't SHA-1 itself, which is actually still plenty strong for password hashing, but rather that the system does not appear to be using a salt. Without a salt, rainbow table attacks are possible even against perfect hashing function -- because users aren't choosing strong passwords. – DepressedDaniel Nov 28 '16 at 21:01
  • @DepressedDaniel the problem with SHA-1 is also that it's too easy too compute making brute-forcing them a possibility. But yes you are correct, their system is not capable (baffling) of salting them. In my case the users have no possibility to choose a password. (although the entropy of the given passwords are also quite horrendous) Another problem is i can't force the user to set a password on first log in because the client wants no personal data required by the users. Having a password without a password recovery path wouldn't be an option. but forcing an e-mail adres isn't either. – Jester Nov 28 '16 at 21:17
  • Note that if SHA-1 of your scenario were replaced by "Take the first letter" as first hashing algorithm, then bcrypting its output would not add security. Therefore, I'd be cautious with just answering "yes" – Hagen von Eitzen Nov 29 '16 at 21:49
  • @HagenvonEitzen well that would just reduce the entropy of the password. (and bcrypting it would still make it more secure just marginally so.) But i guess you're technically correct although that's not what i meant with a weak hashing algorithm :p – Jester Nov 29 '16 at 21:54
  • @Jester I could do even weaker than that ;) – Hagen von Eitzen Nov 29 '16 at 22:00

5 Answers5

20

Yes, hashing it again with bcrypt is a good idea. Do note, though, that it will not give your login code more entropy, it will just make it take longer time to crack. So if it is really low entropy to begin with you might need a very high cost factor to make it unfeasible to crack.

On a side note, in general it is better to just hash with one good hash function than playing around with many, as explained in answers to this question. But you don't have that option, so the arguments there are not really valid for your case.

As for using a pepper, I would recommend just encrypting the hashes instead. It gives the same kind of protection, but offers more flexibility. But it is no replacement for salting.

This and this might be interesting reading for you. Also, Roshan Bhumbra has an interesting suggestion about rehashing with just one function after the first login.

Community
  • 1
Anders
  • 64,406
  • 24
  • 178
  • 215
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/49283/discussion-on-answer-by-anders-does-rehashing-a-weak-hash-with-a-strong-algorith). – Rory Alsop Nov 29 '16 at 13:22
5

Encryption in transit

In your current system it seems that de-facto password is the "SHA-1 hash of this logincode" since possession of a matching hash is sufficient to make a valid file, though it's not clear if it allows the attacker to exploit something directly. However, in this regard, it's no less secure than simply sending a plaintext password - which is appropriate as long as you "get a file" through a secure and encrypted channel, i.e. proper https / sftp / etc.

Encryption in storage

A risk with this system is that if an attacker can obtain a copy of that file, then they can obtain the full passwords of the users. IF you need to store these hashes, then you are right that it would be reasonable to hash them with bcrypt for storage, with the main issue being that you need to be sure that you immediately delete the received SHA-1 hash and no copies of it (e.g. temporary files, backups, caches, etc) remain in storage.

Peteris
  • 8,369
  • 1
  • 26
  • 35
  • Can you explain your first sentence: "In your current system it seems that de-facto password is the "SHA-1 hash of this logincode" since possession of a matching hash is sufficient to make a valid file" I don't fully understand what you mean, i think the logincode is the de-facto password? Or do you mean because one could use a rainbow table to get the original login if one were to intercept the SHA-1 hash? Also if the channel through which this is communicated is not secure than there is nothing i could do to fix this right? – Jester Nov 28 '16 at 12:37
  • @Jester I mean that in the absence of any other components in addition to those that you've described, the attacker doesn't need to know the original logincode if they have the hash. Since you're only receiving the hashed value, they might be able to impersonate the user by simply sending a captured hash instead of actually hashing something. And yes, if the channel is not secure then the SHA-1 hashes are exposed and pretty much mean that the user passwords are freely available to anyone who can snoop this traffic. – Peteris Nov 28 '16 at 12:43
  • I don't understand how they "might be able to impersonate the user by simply sending a captured hash instead of actually hashing something." If i have a form which on submit hashes the input SHA-1 and then bcrypt (all server side of course). entering the SHA-1 hash instead of the original logincode would result into a different hash and thus not match? I can see how this might happen if you hash client side and then send it to the server to check, but i never heard of anyone doing that. Is that what you meant? – Jester Nov 28 '16 at 12:50
  • @Jester as I said, "any other components in addition to those that you've described" - the original post mentions only receiving a file with a SHA-1 hash for authentication, not a separate channel with the full password; it can be *implied* that maybe the file is just used to create accounts and the actual authentication is done elsewhere according to common best practice, but it wasn't stated currently. But anyway, if the channel over which SHA-1 hashes are sent isn't secure then that seems an obvious serious weak point. – Peteris Nov 28 '16 at 13:01
  • Aaah okay, i think i did mention them receiving a letter with the logincode and us receiving the hash of said logincode. But i understand! :) Thanks for the tips though! I'll make sure the channel is secure and that the files get deleted after being processed. – Jester Nov 28 '16 at 13:05
3

I see another option which doesn't seem to have been mentioned, although this would work better if the system which generates the hash could use a Bcrypt.

You just need to update the hash when the user logs in. Although this means you'll have two different hashing algorithms in use at the same time, it gets around the 'issue' mentioned by @Anders regarding using two algorithms on one value.

You can store a value next to the hash to tell the application which type it is, and if it's the SHA-1 hash then you can hash the password they just entered (provided it was correct) and store that.

Roshan Bhumbra
  • 166
  • 3
  • This could be implemented to get rid of the double hashing after first login. but the double hashing still has to be done so it's more reliable until then. If the system could generate a bcrypt hash i wouldn't be here ;') – Jester Nov 28 '16 at 21:20
  • you can rip the existing passwords to avoid a login wait... – dandavis Nov 29 '16 at 19:34
2

If the original hashes are not salted, then you can simply apply any salted hash algorithm to the original unsalted hash that you have received.

It is however important that it is clearly marked in your database that these hashes are using the combined hash algorithm. It is not entirely unlikely that at a later date you will have different users in your database secured with different hash algorithms. At that time it is important that you know the correct function to use for each user in your database.

It is possible to upgrade stored hashes in your database the next time the user logs in. Though it may not be important because bcrypt is only marginally more secure than SHA1 followed by bcrypt.

If the original hashes are salted it becomes more tricky. In that case you can still apply two layers of hashing, but in that case it is very important to store all the salts and only the last hash value.

kasperd
  • 5,402
  • 1
  • 19
  • 38
1

There is an additional danger when wrapping unsalted hashes - the "hash shucking" problem (disclosure: my answer)

Briefly, if an unsalted hash also appears in any other corpus, even those not yet cracked, that hash can be tried directly against a wrapped bcrypt corpus (as if the hash was the password). Once an inner hash is discovered, that raw hash can then be attacked separately at much higher rates than would be possible if the password was directly hashed with bcrypt.

(This is understandably not intuitive, so readers are encouraged to experiment with a practical example, as described in my answer.)

A common mitigation for this is to add a 'pepper' (a static, complex shared salt) to the hashes, and store the pepper separately from the main corpus (ideally, in an HSM, or on a separate hardened authentication server that adds the pepper). The goal is to make the pepper unavailable to the attacker even if they steal the bcrypt corpus, rendering hash shucking (and many other attacks) impossible.

In an upgrade scenario (migrating from a raw hash to bcrypt, using wrapping the old hashes in bcrypt as an interim step), the mitigation is to intercept the plaintext upon the next successful login, and hash the plain directly as bcrypt, eliminating the inner hash. The need for such upgrades is common, and can be tricky. See Michal Spacek's guide to upgrading password hashing.

Royce Williams
  • 9,128
  • 1
  • 31
  • 55