i want to know how to decrypt password.suppose i am using Hash::make("admin123") work perfect but how to decrypt? i already tried below two methods
Crypt::decrypt('$2y$10$v2yO0SCt1vOrVZCM8GWRjOuiV1IM3xQbSeq3klaITWVRqsavjaOPI','$2y$10')
Crypt::decrypt('$2y$10$v2yO0SCt1vOrVZCM8GWRjOuiV1IM3xQbSeq3klaITWVRqsavjaOPI')
Above two give me "Invalid data."
Actually i want to rehash all password like
$users = User->select('password')->where('activated','=',1)->get();
foreach($users as $user){
// when i register user then i am using Hash::make() mechanism
// How to rehash $user->password
}
It's impossible.
More precisely, it's possible, but it's not fast. In fact, it's ridiculously slow. Ridiculously to the point that a single "dehash" would take aeons, if password is hashed correctly. And it's by design, that's precisely why hashes are used with passwords.
Hash-function is a deterministic (i. e. works the same way every time) algorithm that scrambles the given values. It's used for passwords so you don't keep them in plain text, but you still can compare at runtime, whether the given value is the same as the one that has been hashed. The idea is simple: hash is the same for same inputs, hash is different (almost always) for different inputs.
Given a hash, you cannot get the source value. It's not encryption.
If you find yourself in a situation when you need to invalidate the existing hashes, write NULLs instead. Then, during login, if password hash is NULL, then send an email to your user, prompting a password reset due to "a change in your authentication system".
Whether to alert the user on a webpage is up to you, but by telling the user that an email was sent with password reset instructions, you've given a solid clue that the given user exists, this may be useful for a potential attacker. For the paranoids among us.
Related
Is there a way knowing what hash-algorithm is used?
My question is grounded of that I've got an database from a customer with some users and passwords. I have no idea what the passwords are (so it's correctly stored in the database) and the customer would not like to give these passwords away (it's understandable)
I have access to the database and I know that the passwordhash is 60 characters long, but nothing else.
I basically want to create a new user (directly in the database if possible) with a temporary password so I can login to the system - but it's kind of impossible if I don't know how to create the password. Any thoughts?
The system is created in CodeIgniter but I don't know what authentification-method is used.
What data do the passwords contain? Do they contain only 0-9 and a-f, i.e. hex
values, or can they contain other data too? If you want to know the algorithm, it is crucial to answer to this question.
If they contain hex values only, 60*4 = 240 and there is no common algorithm
which gives a hash that is 240 bits long.
It has been suggested that the password contains salt, which might explain the
unusual length.
Why not ask the customer what has algorithm is used? It is understandable that
the customer doesn't want to give away these passwords, but there should be no
objection to giving away the hash algorithm.
okay I am trying to make a log in form to my website in C# it has md5 + salt.. the problem is salt. md5 I can make work but salt just won't work. I made a php that gets the user name, user group id's etc. I have removed tons of instances of salt in the db and it either destroyed log in, or just did nothing. I am wondering if there is an easy way to remove salt?
What do you think is the purpose of the salt? If you could easily remove it, what would have been the reason to add it? You should really take a few minutes to read a tutorial about password hashing.
MD5 is not an appropriate choice to hash passwords, because it is ways too fast. One can calculate 8 Giga MD5 values per second with common hardware nowadays, that makes brute-forcing too easy. Instead use a slow key derivation function like BCrypt or PBKDF2.
To answer your question, you need the stored salt to verify the user entered password. If the user enters the password for login, you calculate a hash with the same salt you used to calculate the stored password in the database, then you can compare the hashes.
What is safer?
I can use either one as I'm using CodeIgniter, but with Sha1, I can't reverse if I ever needed to for some odd reason like I can with encryption.
But I'm still somewhat new to PHP, so if there is a way I can possibly do something like display the sha1 hashed password as stars, so if say your password is "lala123" it would show this to me: "*******" and never ever be able to be shown "lala123", is it possible to do that with sha1? If so, please help me, otherwise I'll use encryption, but only if it's safe to use for passwords. Please let me know :)
Hashing is considered more secure for the very reason that even you cannot restore the password. If you password database is compromised, and the password encryption is reversible, the baddie might decrypt them, especially if the code that does the decryption has been compromised as well. SHA1 is not reversible by design.
You're not supposed to display the password in the UI - ever. The * are just that - an arbitrary number of stars. Disclosing the length of a user's password constitutes in itself a considerable hint to a would-be guesser.
Neither. You should use hashing to keep the passwords secure in case someone gets the password database. But the consensus answer seems to be to use bcrypt, described in this answer. It is a hash function based on blowfish with variable cost so you can tune security versus performance.
This is for a college assignment. At our College they use Microsofts's Active Directory to run their network.
Every month we get asked to change our passwords and when we do so it won't accept any of the previous five passwords we have used, or similar passwords. For example if my password was 'secretpassword1', next month I couldn't use 'secretpassword2'.
However the only way that I can see this being done is if there is either a flaw in the hashing algorithm used to store the passwords; the passwords aren't hashed but encrypted; or worse they are stored in plaintext.
After a quick Google-Fu session it appears that Active Directory will store passwords in regular Windows hashes. So can anyone explain this?
Cheers
P.S. This may be our imagination; perhaps you can reuse a password that is slightly different?
The old passwords are stored (in hashed format) in the AD database. As part of the password change process, this gets checked and/or updated.
It's easy to do if you generate the variants from the new password, not the old password.
Imagine an algorithm that takes a password, and generates a few hundred simple variants of it. So for an input like password1 it would generate the following variants:
PASSWORD1
PasSSword1
password2
password
P#aaW0RD2
....
and a few hundred others. (Note that one of those variants is "password".)
Password crackers have algorithms like these and use them against word dictionaries to generate guesses.
Using this algorithm, we can perform the following steps:
a user sets their first password to be "password".
The system stores hash("password"), and uses this hash to compare whenever a user logs in.
Several weeks later, the user changes their password to "hunter2". The current password hash is changed to hash("hunter2"). hash("password") is stored in the list of N historical password hashes.
Several weeks after that, the user attempts to change their password to "password1". During this change attempt the following steps are performed.
3a) the new password is available in the clear, because the user just entered it. "password1" is used as input to the variant generation algorithm described above. A few hundred variant passwords are generated (in the clear).
3b) for each variant password, the hash of that password hash(variant) is calculated, using the salt for each old password. As noted above, one of the variants of "password1" is "password", so in our list of variant hashes we will have hash("password"). We end up with V variant hashes to test for each old password, V*N hashes total.
3c) The correctly salted version for each variant hash is tested against the current hash, and the previous hashes, for a total V * N binary array comparisons.
3d) One of the variant hashes is hash("password") and one of the stored N historical hashes is also hash("password"). These hashes match exactly, so the password is rejected.
This technique requires V*N hashes to be generated, where V is ~500 and N is ~10. This will only take a few seconds (even with PBKDF2, bcrypt or scrypt) and can be easily performed without disk access.
A note on salt: Changing the salt whenever you change the user's password (which you should definitely do) does make things a bit harder, but you still only need to generate a linear number of hashes, no matter how big your salt is.
Upfront, I'd like to confess to being a complete newbie to cryptography and password security. I'm trying to store passwords in a database being babysat by ruby. My understanding is that plaintext passwords should be appended to a random "salt" and that whole phrase should be hashed by some hashing algorithm such as:
Digest::SHA1.hexdigest(salt_plus_plainpassword)
Once that string is stored in the database, how does one get it out again to verify that what the user entered is correct if there was a now unknown random salt appended to it?
The best way to do it is to store the salt is one for each user and it is generated based on the Time at the point they did it.
It's true that once a person has access to your database they can see the salt for users, but if this has happened you have bigger things to worry about.
The way you check your user's password is that you take their clear text input and crypt it with the salt and then compare the crypted_passwords, if they match they are authenticated. I don't believe that storing the salt is an issue as you will need it. If you are worried about SQL injection attacks you are better off securing your application against them rather than not storing information you need, in this case each users salt.
Theoretically the salt serves two main purposes. The first is to prevent duplicate passwords to end up with the same hash value on the database. The second is to increase the length of the password, thus also increasing the difficulty of an attacker guessing a password.
But there is the problem of storing the salt, if you insert it on the database the second purpose is somewhat defeated in case someone grabs that data, ideally it should be stored on a different location, but this is only necessary if your application is very sensitive!
If the code of your application is not public, I'd say a possible way to circumvent this issue is to generate the salt based on a static value of each user, like the creation date or username, because if someone reads the database it is unclear whether or not you use salt...