My goal is to store the hash and salt of meteor password on another database. So far I've managed to know the hash but not the salt....
Is there a way to deduce the salt used by bcrypt ?
Or is there a way to know the salt used ?
And does Meteor create a new salt each time a password is hashed ?
A "solution" could be the creation of one well known password and deduce the salt out of it if Meteor doesn't change the salt each time.
Any ideas ?
Related
I'm using the FOSUserBundle on a Symfony project, and I would like to know if, when a user changes his password, I can have access to his former password. The one he's supposed to enter in the "current password" field.
I have a system of encryption on my project, and it's partially based on the user's password, that's why I need it, to update the user's encryption settings.
I created a listener when the user changes his password but I don't know how to get his former password. Or current password, whatever.
Thank you for your help !
Short answer: NO. If user won't give you his current password by typing it in form it's impossible to guess his password.
Only option to have access to current user's password is when password is stored in database in plain text which is rather not the case.
The way passwords are stored in db usually is by using hashing function which are designed to be impossible to invert - you are able to hash your password but you can't unhash it.
In theory you could try to use Rainbow tables but it's not something you could use in regular way on every passwprd change because it's very CPU heavy.
encrypt the new password.
compare the hash of the new password and the hash password in the database.
my friend created his platform using laravel, and he encrypted the users password using laravel Hash. I never worked with laravel. I'm building a simple Android application to list all the users from his website, using PHP and Java, and i would like to decrypt the passwords for the login.
I usually use md5:
$password = md5($_GET['password']);
But he used a different hash. My password appears encrypted like this:
Q5joXS5QBA0xdV2Ed2c80e12ac10766d48ef5d8a916e445064091725156d7776958a3937b5cbe79
Thanks.
Some small research seems to show that they are hashed using Bcrypt. This is different to encrypting because it is one way. So to check if the two passwords match, you will need to encrypt the user input with Bcrypt and then check if the two match.
http://laravel.com/docs/4.2/security - Info on BCrypt.
You could use this to check if your passwords match up.
http://www.bcrypt-generator.com/
EDIT: I would advise against using md5 encryption as it is not very secure and it can "decrypted" by brute force.
Example: http://www.hashkiller.co.uk/md5-decrypter.aspx
I have been searching for a preferred location to create a password salt.
For me it makes sense to create the password salt the database level and do the hashing of the entered password + salt at the database level.
But as I am an ultra-noob on login security, I wanted to know which location is best for creating the salt itself.
From what I have read, I have created a stored procedure that takes a userlogin and password and compares the stored salt concatenation to validate if the password entered is correct.
What I need to know now, is where should the password salt be created on a new user account?
My intent is to have a non-refundable password if the user forgets. If they forget it gives them a temp and then requires a change afterwards. As well, if the password changes, I also want to change the salt accordingly.
I have no illusion of total security, only want to mitigate the opportunity.
The place to generate the salt and to hash the password, should be in the code, not in the database.
To hash passwords you need a slow key-derivation function like BCrypt or PBKDF2, but most databases have no implementations of such functions. These functions have a cost factor, which controls the necessary time to calculate the hash-value (the longer the more secure against brute-forcing). The salt as well as the cost factor is usually stored in the same string as the password-hash, so you need only a single field to store the hash.
To verify the password, you first have to search with the username for the password-hash, then the function can extract the used salt and the cost factor, and finally the entered password can be hashed with the same parameters for comparison.
There is another reason to do it in the code, password-systems have to switch to stronger algorithms or have to increase the cost factor in future, then it is much easier to handle backwards compatibility in code, as with SQL statements.
I am using aspnet membership provider and by default HASHED password format were being used behind the scene and recently i got that password retrieval is not possible using that format. so i need to change password format to CLEAR OR ENCRYPTED however after doing this
is there any possible way to change password of existing data through database? OR i need to delete all records and start to create from scratch?
Also how one can handle situation where need to change password format from CLEAR to ENCRYPTED?
No, you will not be able to decrypt a hashed password. Hashing is by definition one-way. The two-way option available is the encrypt option, or clear.
The main function of hashing a password is for one-way encryption. Even internally when values are compared they are compared as hashed values.
[OK, technically one could decrypt a hashed value, but this enters into the realm of hackers, rainbow tables, salt values, and I do not think you wish to go there]
For more please see here
I am very new to web application (ASP.NET). I have source code and database for a complete project.
ASP.NET (Authentication) control is used for login. I don't know the password right now but i can get the login name and password in encrypt format from the database table.
How could I login to the application with only this little information available.
As the control are dynamically created on the pages, it is very hard to debug and find them on runtime.
How could i proceed for login by encrypted password? or is there a way to login by overcoming Authentication control.
The password is probably SHA1 encrypted. Basically what you have to do is SHA1 encrypt the password the user gives you and compare that to the password in your database. Because SHA1 always results to the same thing if the input is the same, you will know that the users given password is correct if both hashes match.
SHA1 encryption is a form of hashing and cannot be reversed.
No, hashed passwords in the database are non-reversible intentionally. This keeps anyone (a hacker?) from reading your database and being able to log in.
As Sam152 said, the passwords are likely SHA1 hashed, so if the passwords are not stored with salt, you can build a rainbow table to find the original password. If they are salted, you need to know the salt to build the rainbow table as well.
You could try implementing custom MembershipProvider by derriving from this class. Then you just override method ValidateUser to meet your requirements. Also remember to modify Web.config.
The point of hashed passwords is that a they can't be used by folks not knowing the decrypted password.
There should be a way to reset the password for users. You could do this and log in based on the reset password.
If you are trying to log in to an active user's account, you may want to consider the implications in doing so without their knowledge (if that is the case). However, if it is just a test user, reseting the password is probably the least cumbersome way. That functionality or procedure should probably be part of web app anyway.
If it's the standard ASP.NET membership stuff, I think it uses a stored proc to check the DB. Just change that and have it return true or whatever.
Adding to the above answers SHA1 encryption output is 40 byte. You should check the length of the encrypted password to get an idea about the kind of encryption..since hash algorithm has predefined no of output bytes, this would help you map with the kind of algorithm and then you should look for possibile salt usage as #MattGWagner said...is the tables in database that stores user information seems like aspnet_users,aspnet_membership, etc? Then this should be the standard authentication provided by windows..Just google and see how it works