Long story short I want to be able to read passwords stored in our database to be able to query weak passwords for our employees as there are currently no restrictions. What I've been doing in the past is changing it from the front end to see what it looks like on the backend. For instance this is what "password" looks like on the back end JXm7CJyoCBnURIrneTtflA== .
I'm not sure if this is possible, or what type of encryption is used. Any help would be great!!
Thanks
This particular field is Base64 encoded, and has 16 bytes if you decode it (Convert.FromBase64String). This smells like a MD5 (hash algorithm) - especially if other fields have also 16 bytes when decoded. There is no way in hell how to decrypt hash (there are some options like rainbow tables but you can't be 100% sure). Algorithm works like this: you hash password in db, you hash whatever user puts in as password when he logs in and hash it as well - if hash matches user has entered correct password.
Related
By using salt, I understand that password would be added with an random generated salt before storing into database.
However, I dont quite sure whether the salt is unique for each passwords or all password is only mixed the same "random generated" salt
For example，
Under my application, there are two users and there two passwords: user1password1 and user2password2
Their passwords would be mixed with salt for sure. But, before storing into db, the results are
user1password1 + salt , user2password2 + salt
or
user1password1 + salt1 , user2password2 + salt2
Ideally your salt should be unique per user or per password.
Now, as you said before storing the password in a DB, you should hash them with a password-based KDF such as Argon2. (Not with a hash function.)
Using a single salt
There is one main problem if you use the same salt for all of your password: it lowers the cost of an attack against your database because an adversary, Eve, can take a dictionary of "common password" let us call it "rockyou.txt", and it is enough for her to try and hash all of the passwords contained in rockyou.txt once using that salt to try and break some of your users' password.
Basically this means the work-factor to find the pre-images of multiple hashes in your database is low.
Using different, randomized salts
Whereas using a different salt for each user (or each entry in the password database even) means that Eve has to re-do the computations where she tries to hash all the words in the rockyou.txt dictionary to try and find the pre-image of a single hash in your database.
So here, the work-factor is large, since it has to be re-computed for each single password hash.
So if you can store one large (128 bits ideally or more, but 64 bits would be okay-ish is storage is a concern) random salt per password, please do it and make sure you are never storing plaintext password, but only their hashes.
Need some help with an application that sadly i cant get access to anymore as the author no longer supports it.
anyway the application has a .mdb file that when opened i get a list of user's and the associated password but the password box is formatted in the following way A8DB6C7E643D04A361D9F9CA55E3D6B1.
Is this just rubbish or can i get the password from it?
From the used characters one can guess that the string is HexEncoded, means two characters describe one byte. This would result in 16 bytes, which is the same length as an MD5 hash produces.
It can be an MD5 hash or it can be something different, but if all passwords are stored with 32 characters, it is very likely a hash and the password cannot be retrieved, only cracked.
Is it possible to decrypt a SHA1 string in VB.Net, knowing the key?
I have seen "decryption" of credentials before, however - in Java: http://pastebin.com/P0LuN00P
The entire point of SHA1 is to make this impossible.
However, SHA1 has weaknesses which make this less impossible.
You should use SHA512 to make it more impossible.
You might be looking for Rijndael, a (good) symmetric encryption algorithm.
I think you got SHA1 wrong.
SHA1 is not an encryption algorithm, it is a hash function.
A hash function is a function taking some unconditionally long argument string and transform that string to a much smaller string, called the hash. It is very hard to get from a hash to the string used to generate the hash. Actually, since the input are arbitrarily long, there are multiple such inputs that give the same hash. Two such inputs are called collisions. Therefore you really cant "decrypt" a hash, you can find a input which gives the same hash though.
Commonly hashing functions are used to hash a user password, store it in a database on the server. When the server is supplied a password from a user, the server checks to see if the password is correct by checking that hashing the password gives the same result as stored in the database.
If a malicious user grabs what is stored in the database, he is unable to know the actual password since it is very hard to go from hash to the string used to generate the hash.
SHA1 isn't encrypted, it's hashed. So no, it's not possible to decrypt it. You might try a Rainbow Tables: http://www.freerainbowtables.com/
I've got an old application that has user passwords stored in the database with an MD5 hash. I'd like to replace this with something in the SHA-2 family.
I've thought of two possible ways to accomplish this, but both seem rather clunky.
1) Add a boolean "flag" field. The first time the user authenticates after this, replace the MD5 password hash with the SHA password hash, and set the flag. I can then check the flag to see whether the password hash has been converted.
2) Add a second password field to store the SHA hash. The first time the user authenticates after this, hash the password with SHA and store it in the new field (probably delete their MD5 hash at the same time). Then I can check whether the SHA field has a value; this essentially becomes my flag.
In either case, the MD5 authentication would have to remain in place for some time for any users who log in infrequently. And any users who are no longer active will never be switched to SHA.
Is there a better way to do this?
Essentially the same, but maybe more elegant than adding extra fields: In the default authentication framwork in Django, the password hashes are stored as strings constructed like this:
hashtype$salt$hash
Hashtype is either sha1 or md5, salt is a random string used to salt the raw password and at last comes the hash itself. Example value:
sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4
You can convert all your MD5 Strings to SHA1 by rehashing them in your DB if you create your future passwords by first MD5ing them. Checking the passwords requires MD5ing them first also, but i dont think thats a big hit.
php-code (login):
prev:
$login = (md5($password) == $storedMd5PasswordHash);
after:
$login = (sha1(md5($password)) == $storedSha1PasswordHash);
Works also with salting, got the initial idea from here.
I think you've already got the best possibilities. I like #1 more than #2, since there's no use for the md5 once the sha is set.
There's no way to reverse the MD5, so you have to wait for the user to authenticate again to create a new hash.
No - basically you'll have to keep the MD5 in place until all the users you care about have been converted. That's just the nature of hashing - you don't have enough information to perform the conversion again.
Another option in-keeping with the others would be to make the password field effectively self-describing, e.g.
MD5:(md5 hash)
SHA:(sha hash)
You could then easily detect which algorithm to use for comparison, and avoid having two fields. Again, you'd overwrite the MD5 with SHA as you went along.
You'd want to do an initial update to make all current passwords declare themselves as MD5.
Your second suggestion sounds the best to me. That way frequent users will have a more secure experience in the future.
The first effectively "quirks-mode"'s your codebase and only makes sure that new users have the better SHA experience.
If the MD5's aren't salted you can always use a decryption site/rainbow tables such as: http://passcracking.com/index.php to get the passwords. Probably easier to just use the re-encode method though.
Yes you should know the real password first before you convert it into sha-1..
If you want to find the real password from md5 encrypted string, you can try md5pass.com
In my program, we store a user's IP address in a record. When we display a list of records to a user, we don't want to give away the other user's IP, so we SHA1 hash it. Then, when the user clicks on a record, it goes to a URL like this:
http://www.example.com/allrecordsbyipaddress.php?ipaddress=SHA1HASHOFTHEIPADDRESS
Now, I need to list all the records by the IP address specified in the SHA1 hash. I tried this:
SELECT * FROM records
WHERE SHA1(IPADDRESS)="da39a3ee5e6b4b0d3255bfef95601890afd80709"
but this does not work. How would I do this?
Thanks,
Isaac Waller
Don't know if it matters, but your SHA1 hash da39a3ee5e6b4b0d3255bfef95601890afd80709 is a well-known hash of an empty string.
Is it just an example or you forgot to provide an actual IP address to the hash calculation function?
Update:
Does your webpage code generate SHA1 hashes in lowercase?
This check will fail in MySQL:
SELECT SHA1('') = 'DA39A3EE5E6B4B0D3255BFEF95601890AFD80709'
In this case, use this:
SELECT SHA1('') = LOWER('DA39A3EE5E6B4B0D3255BFEF95601890AFD80709')
, which will succeed.
Also, you can precalculate the SHA1 hash when you insert the records into the table:
INSERT
INTO ip_records (ip, ip_sha)
VALUES (#ip, SHA1(CONCAT('my_secret_salt', #ip))
SELECT *
FROM ip_records
WHERE ip_sha = #my_salted_sha1_from_webpage
This will return you the original IP and allow indexing of ip_sha, so that this query will work fast.
I'd store the SHA1 of the IP in the database along with the raw IP, so that the query would become
SELECT * FROM records WHERE ip_sha1 = "..."
Then I'd make sure that the SHA1 calculation happens exactly one place in code, so that there's no opportunity for it be be done slightly differently in multiple places. That also gives you the opportunity to mix a salt into the calculation, so that someone can't simply compute the SHA1 on an IP address they're interested in and pass that in by hand.
Storing the SHA1 hash the database also gives you the opportunity to add a secondary index on ip_sha1 to speed up that SELECT. If you have a very large data set, doing the SHA1 in the WHERE clauses forces the database to do a complete table scan, along with redoing a calculation for every record on every scan.
Every time I've had an unexpected hashing mismatch, it was because I accidentally hashed a string that included some whitespace, such as "\n".
Just a quick thought: that's a very simple obfuscation. There are only 232 possible IP addresses, so if somebody with technical knowledge wanted to figure it out, they could do that by calculating all 4 billion hashes, which wouldn't take very long. Depending on the sensitivity of those ip addresses, you may want to consider a private lookup table.
Did you compare the output of your hash algorithm with the output of MySQL's SHA1()? For example for IP address 1.2.3.4?
I ended up encrypting the IP addresses, and decrypting them on the other page. Then I can just use the raw IP address in the SQL query. Also, it protects against brute force attacks, like Autocracy said.