-1

I have a table in the backend where I store the password after converting it to hash.HASHBYTES('SHA2_512', 'Welcome1'). It is stored in the backend like this:

0xDA07C08A2C2EF3710E688BFF476A8A09D52D6D34B6EE3C41A4B1F58F2949792EF20079565CA0D78E2758B33B50A13C9829C08BDF670DC802E627F289364D203A.

Now I want to show this password from backend in front end after converting it back to 'Welcome1'.

I am not able to do that and getting password as system.byte[]. Can anyone please help me to get 'Welcome1' as the value in front end.

The requirement is to create a page for admin where he can see all the users,their details including password.If he clicks on an user(link button) all his details should appear in the text boxes including password.I understand it is not a good approach to show the password,but would like to know the all the options we have.If there are not any,I can let the business know this is not possible.Thanks so much for your help.

mahesh suraparaju
  • 3
  • 2
  • 10
    The entire point of hashing is to that you _can't_ reverse it. Why on earth would you think a reversible password is secure? – maccettura Jan 26 '18 at 17:22
  • 2
    SHA hases are too fast for passwords. You need to use bcrypt or scrypt or PBKDFv2. – SLaks Jan 26 '18 at 17:23
  • 3
    You should never even have the ability to show a user their password. There is a reason why popular websites never show you your password. Security minded websites send you a password reset email, so that you must have access to that registered email, and then they can replace the password in the system, without exposing their hashing algorithm. – Marcus Parsons Jan 26 '18 at 17:29
  • 2
    To get the value `"Welcome1"` in the front-end do something like this: `myLabel.Text = "Welcome1";`. The rest of the question is impossible to give a satisfactory answer to because it is impossible to do. You cannot easily reverse a hash, if you can you've picked the wrong hash algorithm and clearly you haven't understood the purpose of the hash to begin with. – Lasse V. Karlsen Jan 26 '18 at 17:36
  • 1
    because the question is not answerable – MikeT Jan 26 '18 at 17:57
  • 1
    I think we are missing some information here, what you want to do is a VERY bad idea, so why do you want to show the password anywhere in your system? – MikeT Jan 26 '18 at 17:59
  • Thanks for your responses.I agree this is not a good approach.But we are developing a tool for admin where he can add the new user and also admin can see who are all the users and details.If he wants he can update including password.In the screen we are providing all text fields to add user details and the same fields need to be updated as well.So if I click on an userid all his details along with password should be appearing(though masked) in the text boxes. – mahesh suraparaju Jan 26 '18 at 18:54
  • Also I have seen few applications where the admin provides the password in the forgot password link.How do they do that?Just curious.Maybe they do not store the password as hash? – mahesh suraparaju Jan 26 '18 at 19:03
  • 1
    If you want an admin to be able to enter a new password that is completely different than displaying the current password. That is an incredibly simple task as opposed to what you actually asked here. – Sean Lange Jan 26 '18 at 19:11
  • No.What I meant was admin in few applications provides your own password in the forgot password link and not the new one. – mahesh suraparaju Jan 26 '18 at 19:15
  • 2
    @maheshsuraparaju - Storing passwords in a "reversible" hash is basically equivalent to storing then in plaintext. For more reading on why this is bad see [You're Probably Storing Passwords Incorrectly](https://blog.codinghorror.com/youre-probably-storing-passwords-incorrectly/) by Jeff Atwood and [Naming and Shaming the Plaintext Offenders](https://krebsonsecurity.com/2012/06/naming-and-shaming-the-plaintext-offenders/) by Brian Krebs – dbc Jan 26 '18 at 22:47
  • Please also upgrade your password hashing to scrypt, bcrypt, pbkdf2, or argon2. It looks like you're actually having SQL Server do the hashing, which is a terrible idea - SQL is incredibly slow at it, but if you insist on that, please instead use [PBKDF2-HMAC-SHA-512 in SQL Server](https://stackoverflow.com/a/19898192/1967612), or get [the same thing in my github repository](https://github.com/Anti-weakpasswords/PBKDF2-MSSQL-Custom-A); github has more comprehensive test vectors. Choose the highest iteration count you can afford CPU for. And start doing hashing in your app! – Anti-weakpasswords Jan 27 '18 at 05:46

2 Answers2

6

Let me summarize my answer first and then go into more detail:

You can't!

More importantly, you shouldn't even try!.

By hashing the password you have performed a one-way calculation/transform from the password to something else, usually a sequence of bytes, which is again usually represented as a string of hexadecimal characters.

The "one-way" part of this should not be taken lightly.

First of all, can you reverse a hash? No, you can't. But you can guess what the value could be.

How then could you make this guess?

There are several methods available to you:

  1. Brute-forcing
  2. Exploiting a weakness
  3. Rainbow tables

Brute-forcing

Brute-forcing would basically mean that you would try every possible password until your hashing function returned the same hash. At that point you have a password that might match the hash you have in your database. Depending on the password you might not have the password, but again depending on the circumstances this might not mean much.

Brute-forcing good hash functions, however, is infeasible, unless you intend for your computer to stay online for many times the life of the known universe, past, and future alike.

For brute-forcing SHA-512 it would take ~3.7 * 10^64 years to complete (not verified, lifted from @emboss' excellent answer here).

Exploiting a weakness

The brute-force attempt might be shortened down drastically, however, if there is a weakness in the algorithm that you can exploit. Unfortunately, no such weakness is currently known for SHA-512.

Salt

Unfortunately, if you haven't used a salt to add some randomness to your hash, you are actually weak to the next possible way of breaking a hash.

A salt means that for evey password you want to hash you generate a random value as well, you then combine the password with this random value, then you perform your hash function on this and get your hash. You then store the random value + the hash in your database.

More below in the rainbow table section why this is a good idea.

Rainbow Tables

Rainbow tables mean that you keep a very large table of all known hashes for all known password and character combinations up to a certain length. You could then simply look up the hash in that table and get back a matching password. Just as with the brute-force you would get a password, and depending on the chance of collisions, it might not be the password, just one that hashes to the same value.

These tables, to boot, is very large. For a SHA-512 rainbow table up to 9 characters you are talking close to a terabyte of data (from this answer by @LateralFractal).

For even longer passwords the size of these tables quickly spiral out of control.

Now, I mentioned salt above. If you have a salt for each password, and each salt is random (if you use the same salt for every password you're in no better shape), then you basically need a rainbow table for each salt, meaning you have to generate these tables yourself, for each password you want to break. This also takes a long time. Not universe-lifetime long, but impractical long for most passwords and their worth.

Conclusion for how: You can't, you simply can't. There is no practical solution to reversing a hash back to its password.

Why shouldn't you be doing this?

The sole reason for hashing a password (usually with a salt as well) is to avoid actually storing the password to begin with.

Many users (most?) use the same passwords on a lot of sites so if one site is breached, and a data-dump is made available, and the passwords are either stored in a reversible manner or using basic hashes that can be reversed using rainbow tables or brute-forcing, then that users accounts on many sites suddenly become compromised.

Additionally, and this is important for you, the owner of the breached site won't be looked upon with happy eyes as they purposefully used a broken way to store the password (hashes) in their database. You don't want to be that guy.

So this is why you shouldn't be doing this. By this I mean that once you understand that you cannot reverse the hashes back to their passwords your response should not be to switch to some other way of storing the passwords that allow you to reverse it.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
0

The entire point of hashing the password for storage in the database is that it's NOT reversible. You can't get the password back from the hash. You shouldn't have a way of getting the password back to the plaintext version in case someone manages to get ahold of your data

Bacskay
  • 396
  • 4
  • 12
  • 2
    This is _also_ not an answer, its a comment. You should have enough rep to comment. – maccettura Jan 26 '18 at 17:28
  • That's because there IS no answer to this.... – Bacskay Jan 26 '18 at 17:29
  • Yet you provided an answer? If you yourself believe this question is unanswerable why would you answer in lieu of commenting? – maccettura Jan 26 '18 at 17:30
  • 4
    No, actually, if someone asks "How can I do X?" and the answer is "You can't do X because that is impossible!", then that **is** the answer to that question. We know that in this case, this is not an opinion, it's a fact. Therefore it is a legal answer. If not then we need a close-question choice of "Unanswerable question". – Lasse V. Karlsen Jan 26 '18 at 17:34
  • @LasseVågsætherKarlsen do we drop all standards of what a good answer is then? The comments provided no less detail than this "answer" – maccettura Jan 26 '18 at 17:37
  • 2
    Then perhaps you should stop saying "this is not a (good) answer" and instead say what an acceptable answer would be? – Lasse V. Karlsen Jan 26 '18 at 17:38
  • Thank you @LasseVågsætherKarlsen. I felt like I'm going crazy here because there isn't an answer to this. It's impossible to do. Props on the great detailed answer by the way =) – Bacskay Jan 26 '18 at 18:13