I'm in the middle of development and I need to test my login/password api.
Problem is in the database the password is encrypted.
I have the following information.
key
iteration
salt
Is this enough to recover the password?
By the way I can edit these values as well if that will help.
I think you misunderstood, how a password API works. You cannot reverse a properly hashed password, but you can validate an entered password against the stored hash.
To validate the entered password, you need to calculate the hash again, with the same parameters you used to create the first hash. Then you can compare the two hashes, if they match, the password was the same.
You cannot reverse PBKDF2, but you could brute-force the common passwords to see if any of them matches. If a random salt is used every time, then you will need to do that for each password independently. If a large iteration count is used then prepare for it to take very long.
First, you should just reset it.
Second, you can recover it if and only if the password was weak (assuming correctly implemented PBKDF2), and you either know which HMAC it used (probably was PBKDF2-HMAC-SHA-1 - test with a known password), or you're willing to spend time trying several and hoping.
Try a tool like oclHashcat that's designed for password cracking - note PBKDF2 generic at the end of the list of examples for this, preferably with one or more good GPUs.
Alternately, if you're just testing your password API, you can run the test vectors at my Github repository through it and see if your results are correct or not.
Related
Is it possible to take an original hash value, and then decode it back to the original string?
hash('sha256', $login_password_for_login) gets me a hash, as shown below, but I'd like to go from the hash value back to the original string.
With $login_password_for_login = 12345, the hash function gives me this:
5994471abb01112afcc18159f6cc74b4f511b99806da59b3caf5a9c173cacfc5
I'd like to be able to retrieve the original number or string that I had for the login password. How do I reverse the hash and get that original string?
You don't 'decrypt' the hashes because hashing is not encryption.
As for undoing the hash function to get the original string, there is no way to go from hash to original item, as hashing is a one-direction action. You can take an item and get a hash, but you can't take the hash and get the original item.
Make a note that hashes should NOT be confused with encryption; encryption is a different process where you can take an item, encrypt it with some type of key (either preshared or symmetric keys like PGP keys), and then later decrypt it. Hashes do not work that way.
In comments, you indicate that you're trying to save a passcode in the database. The problem is, you don't want someone who can breach the DB to be immediately be able to decrypt passcodes, which is why hashing is so attractive.
The idea, then, is that you would consider using salted hashes, storing only the salt on a per-user basis in the DB as its own record, and then store the salted hash of their original password string in the database.
Then, to verify a password is entered proper, get the salt from the DB, get the user input for a given password, and then using the salt from the DB, get the salted hash for that input. Take that resultant hash and compare it to the salted hash stored in the DB. If they match, you have a validated password; if they don't match, it's invalid.
This way, there's actually no decryption of any passwords readily doable, which means in a data breach situation of your site the passwords are not easily able to be retrieved. (This doesn't rule out someone breaching your database, copying down the data, and trying to brute-force the passwords, but depending on what you enforce for password complexity and the effort a hacker wants to actually go through to get credentials, this is less likely to happen)
I'd write an example of this in a language I understand, but as you don't define what language you're working with, it's not going to be possible for me to write a useful example for you here.
That said, if you're working with PHP, you may find this document on crackstation.net about doing secure salted password hashing properly; there's already PHP implementations to do this proper so you wouldn't have to write your own code, supposedly.
Hashes cannot be decrypted, as they are not encryption.
Although the output of a hash function often looks similar to that of an encryption function, hashing is actually an extremely lossy form of data compression. When I say "extremely lossy", I mean "all of the original data is destroyed in order to get a fixed length." Since none of your original data remains, you cannot decrypt a hash.
That being said, hashes can be used to emulate encryption. What you do is that, when a person registers, you make a tuple containing the hashes of their username and password. Then, when somebody tries to login, you compare the hashes like this*:
import hashlib
from login_info import logins # This is an array containing the tuples.
def hasher(string: str) -> bytes:
stringer = bytes(string)
return hashlib.sha256(stringer).hexdigest()
def login(username: str, password: str) -> int: # Returns 0 if login correct, else 1.
user = hasher(username)
pass = hasher(password)
for i in range(len(logins)):
if logins[i][0] == user:
if logins[i][1] == pass:
return 0
else:
return 1
else:
return 1
* Nota Bene: I am using Python 3 for the example, as my PHP and Javascript are a little out of practice.
EDIT: On second thought, it is actually possible to (somewhat) decrypt a hash. Basically, you take the hash and then try every entry in the corresponding section of the hash table to see if it's right. This is why you should always salt password hashes.
I have a database of similar integers by the fact that they all share the same first 3 numbers:
7537463746
7536735325
7538236775
7538273826
...
Each one is associated to a user, and they are all almost exposed to the public, meaning they are sent as a sort of peer discovery, but not directly shared. I don't want the bare integer to be accessible, so I thought about hashing them with a one-way hashing function like MD5.
Since the output is not reversible like encryption or compression algorithm do, it looks great. But there's a problem; Getting the integer database is easy and inevitable, so looping through them, hashing the loop results and comparing all the hashes to the ones sent through peer communication is going to be a trivial job for malicious users.
The schema is something like this:
user1[hash(integer1),hash(integer2)...] -> |server hash database| ->
↓
↓
hash(integer1) = user8
hash(integer2) = user40
A malicious user will get user1 integers data by social engineering or other means and hash all of them to see if they're in the database by adding them to his peers data.
Now, is there any hashing algorithm to avoid this type of situation? I need the peers to communicate without giving out their integers data but still both mutually associate the same integer to a unique hash. In alternative, is key signing the only solution? I would like to avoid it since it will make the whole system slower.
Have you thought about salting your MD5? What that means is that you have some sort of secret key that only your application knows. This is actually always a good practice. So rather than doing this...
md5($userId)
You would append the "salt" inside of the MD5 like this...
md5($userId . 'this is a secret shhh!')
Now they can't get the integer from the MD5.
I'm making a forget password feature in my web app, problem is I store user's password using:
Hash::make('_their_password_')
Is there any way to re-hash it back or any recommended approach for this?
The point of hashing a password is that it's (supposed to be) an irreversible operation. If your database is compromised, the attacker will gain access to the hashes, but not to the passwords. That way the attacker can't log in with the users' passwords on other sites.
Make a "we'll reset your password" feature instead of a "we'll send you your password" feature.
Note that there are also other best practices you absolutely should be following regarding password hashing, to make sure the "supposed to be" above actually holds, and to further minimize the impact if your site is compromised. Laravel's Hash class seems to already be using the password-appropriate hash function Bcrypt. However, make sure you're using a salt when you're hashing your password.
The Laravel's Hash method cannot be reversed.
One way encryption is the best way to store user passwords, or other sensitive data.
One way means that your data can be converted into an encrypted string, but due to a complex algorithm with painful maths, reversing the process is not possible. This makes storing passwords a doddle! Your customers don't have to worry about you knowing their passwords, but you are still able to compare them (by hashing the password they provide) or change the password if needed.
If you need to reverse, you can use Crypter class.
$secret = Crypter::encrypt('I actually like Hello Kitty');
$decrypted_secret = Crypter::decrypt($secret);
Read more about encryption here http://codehappy.daylerees.com/encryption
If you want to verify the content of password with other value use the following.
return Hash::check($value, auth()->user()->password);
Anybody can help me regarding the database postgres?
I need to hide the value in table that was created.I need to hide the data password as like below example:
username password
ana 123
I want the password appear like *
Can anyone help me? Thank you in advance.
Take a look at pgcrypto module for some more options (like Extended DES crypt and PGP encryption). I don't recommend using MD5, because (IMHO) it's easily breakable nowadays (especially without any salt). Better choice is SHA-512 (or some of SHA-3 candidates: BLAKE, Grøstl etc.).
I think that it's good idea to check your hiding method against some (possibly GPU-accelerated) tools like hashcat. It really depends how valuable data you want to store.
The usual, and best, way is to store the MD5 of the password and compare that with the MD5 of the password entered. It fairly safe (but brute force can crack it given enough time).
One standard method of doing that sort of hiding is by creating a view, with all columns except the password column (or all columns, then '*' AS password). For the db user the application uses to connect, grant read access to the view, but remove read access for the source table. That way there is no chance of the application gaining access to the field.
Something like:
CREATE VIEW visible_users AS
SELECT username, '***' as password
FROM users;
Then make sure the privileges are managed appropriately:
REVOKE ALL ON users FOR app_user;
That said, you probably shouldn't be storing passwords in a database in plaintext -- it's a major potential security issue.
I need to take a user's email address and somehow manipulate the value to come up with an auto-generated password. I want to make sure that I can re-create the same password whenever a user needs to retrieve their password.
Is there a standard way of doing this? Is this what a "hash" is? I would be greatly appreciative if someone could point me in the right direction! :) Once I know where to look, I can do the research myself.
Thanks!
Sunny
Yes, that's what a "hash" is. However, I would strongly caution against this approach, because it means that someone who's good at cryptographic analysis could potentially generate the password for any user on the system, just by knowing their email address.
Standard practice in the case you're suggesting is to actually reset the user's password with a new, random password when they forget their password. That keeps their previous password "safe," so that someone happens to intercept the email with their password, it will only contain a random password rather than a password that the user very likely uses for every other website they log in to.
After a password reset, users should be encouraged to change their password when they first log in.
A hashing function does do what you're looking for - it takes some input x and generates a digest d that will be the same whenever you give it input x again.
A better definition from wikipedia, that explains this property:
Determinism
A hash procedure must be deterministic—meaning that for a given input value it must always generate the same hash value. In other words, it must be a function of the hashed data, in the mathematical sense of the term. This requirement excludes hash functions that depend on external variable parameters, such as pseudo-random number generators that depend on the time of day. It also excludes functions that depend on the memory address of the object being hashed, if that address may change during processing (as may happen in systems that use certain methods of garbage collection), although sometimes rehashing of the item can be done.
However, if this is for password retrieval, I would advise against it. Instead, I would recommend the approach of sending them a link to reset their password, and then have them reset their password.
If you are doing some sort of password reset system, you should just randomly generate a password to their email and than force them to change it on initial login. If they need to reset their password at some other time, than they can go through the same process again.
Something like the md5 function in PHP would be a good place to start. However, why would you need to recreate the same autogenerated password if the user lost it ? Personally, it would make more sense to just generate a new random one.
A Hash is like a fingerprint. If you have the original value (the password for example), you can get the fingerprint and compare to the one you have in your database. But with the fingerprint you have in the database, you can't recreate the original value (you can't create an human from a fingerprint).
It seems to be what you want. But even so it could be not what you need. Generating a password from the hash of an email address means that anyone that know how you hash your email address will potentially know every password.
If you're looking to a password recovery system, you should instead use a Self-service password reset system.
The users says that he forgot the password
You send a unique key (that you store in your database) to this user by a secure mean (usually mail).
The user confirm that he forgot the password by giving you the unique key previously used. This way you're sure that the user is the owner.
You generate a totally random password that you store (in the hashed form) in your database and send it to the owner by the previously used secure mean.