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/
Related
Is it safe to hash extremely complicated password (longer than 25 chars, any ascii chars even binary) with SHA1 ?
Actually, the password represent a tokenID but I don't want to store it like this in the database, i prefer to hash it for more security.
The password (token) is valid only for 14 Days and I need to hash it the most faster as possible (so no way to use something like bcrypt)
What must be the ideal length of the Password (token) ?
In the general case, no. "Complicated" it may be, but cryptographically random it probably is not.
A bare minimum would be applying an RFC2104 HMAC with a secret key (pepper); however, a more appropriate alternative that can, if you absolutely insist, still be quite fast would be to use PBKDF2-HMAC-SHA-256 and ignore all rules of security regarding a sufficiently high iteration count, i.e. choose an iteration count of 10, instead of 10,000.
For password/token hashing, of course, never request more bytes of PBKDF2 output than the native hash function provides - 20 for SHA-1, 32 for SHA-256, 64 for SHA-512.
I have several example implementations of PBKDF2 at my Github repository that may help, and there are others in other languages, of course.
Use a cryptographically random per-password (per-token) salt.
I am working with a database that contains sensitive information (SSN, credit card details, etc.). I am looking for a method to secure the data.
I would like to encrypt the data when I bring it in from the outside source but also decrypt it when my users access the data via an application that uses the database as its back-end.
I know of the two methods below but I am curious to hear if there is another method I could use.
Examples:
ENCRYPTEDBYPASSPHRASE({PASSWORD}, {FIELD})/DECRYPTBYPASSPHRASE({PASSWORD},{FIELD})
-- This allows me to set a custom password but could be read through the stored procedures.
HASHBYTES('SHA_512', {PASSWORD}+CAST({SALT} AS NVARCHAR(36)))
-- This seems the most secure but I do not know how to decrypt the data from here.
Is ENCRYPTEDBYPASSPHRASE as secure as it gets in this case?
Encryption turns data into a series of unreadable characters, that aren't of a fixed length.
A hash is a string or number generated from a string of text. The resulting string or number is a fixed length.
The key difference between encryption and hashing is that encrypted strings can be reversed back into their original decrypted form if you have the right key and hashing is good to store passwords.
1) If you want to use hashing for security of your data then there are many types of algorithms but SHA and MD4/5 is wildely used algorithms.
For example, as demonstrated below, hashed output with MD5 algorithm produces a 16 bytes long value whereas SHA1 algorithm produces a 20 bytes long value:
SELECT HASHBYTES('MD5', 'Test String') AS Col1, HASHBYTES('MD5', 'Test String') AS Col2 GO
SELECT HASHBYTES('SHA1', 'Test String') AS Col1, HASHBYTES('SHA1', 'Test String') AS Col2 GO
2) and if you want to use Encryption then there are two primary types of encryption, symmetric key encryption and public key encryption.
Example:
To create a symmetric key, we first need to setup our database with a master key and a certificate, which act as protectors of our symmetric key store.
Create a Database Master Key:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘myStrongPassword’
Create a Certificate:
CREATE CERTIFICATE MyCertificateName WITH SUBJECT = 'A label for this certificate'
Create a Symmetric Key:
CREATE SYMMETRIC KEY MySymmetricKeyName WITH IDENTITY_VALUE = 'a fairly secure name', ALGORITHM = AES_256, KEY_SOURCE = 'a very secure strong password or phrase' ENCRYPTION BY CERTIFICATE MyCertificateName;
Encrypting and Decrypting Data:
Open the Key:
Before you can start encrypting or decrypting data, you must first initialize the key. This is done with the following piece of code.
OPEN SYMMETRIC KEY MySymmetricKeyName
DECRYPTION BY CERTIFICATE MyCertificateName
Encrypting data
You can encrypt data by using the EncryptByKey function, like so:
DECLARE #Result varbinary(256)
SET #Result = EncryptByKey(Key_GUID('MySymmetricKeyName'), #ValueToEncrypt)
Note that the result of the above encryption is of type varbinary(256), and if you would like to store the value in a column to use this type.
Decrypting Data:
You can decrypt data by using the DecryptByKey function, like so:
DECLARE #Result varchar(max)
SET #Result = DecryptByKey(#ValueToDecrypt)
You can not decrypt a hash (edit: Unless it has been compromised as a whole), that's the point of a hash. If you were to only compare a hashed value against your hash (such would be the case for logging into your app, for example - never store passwords in cleartext) this would be an easy app-side job.
I found this very handy article over on security:
https://security.stackexchange.com/questions/16939/is-it-generally-a-bad-idea-to-encrypt-database-fields
that should help you on your way.
In re: 2nd option: A hash is a one way operation. It generally doesn't get done with the intent to unhash it. (Consider a password. It gets hashed and a 256 byte string produced. Rather than decode the hash produced and comparing it to the naked user input, the user's input is hashed and the two hashes are compared.)
I think you're looking for a data access layer written with knowledge of your encryption method. That's something you'll have to create on your own. (That is use stored procedures, functions, and views to read data from it's encrypted at rest state, decrypt it, and return it to the caller. Deny access to the users to the underlying tables. Create a stored procedure GetAccountNumber, etc. [You'll note that in these cases the primary key has to be unencrypted so you can find it. Other data will necessarily need to be stored in plain text so you can properly index and search it. You don't want to find yourself in a situation where you have to cycle through every record in a table, decrypting each record, to find a matching address.])
There is transparent data encryption (TDE) available in Enterprise editions of Microsoft SQL Server. With TDE the data is encrypted at rest and anyone who can access the database will have access to the unencrypted data. This is also true for the data access layer method. At some point the secret gets exposed. Where that occurs is up to the design. TDE can be configured in many different ways.
If for PCI requirements I'd go the route of TDE. Don't have Enterprise? Pony up for the upgrade.
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.
I asked a question yesterday about secure hashing, which got me thinking about how one would actually go about breaking a password created with a custom hashing algorithm. My current (very unsecure) password script uses an iteration of sha1 on the password, and then an iteration on the hash generated by that prepended with a 3 digit salt.
$hash = sha1($pass1);
//creates a 3 character sequence
function createSalt()
{
$string = md5(uniqid(rand(), true));
return substr($string, 0, 3);
}
$salt = createSalt();
$hash = sha1($salt . $hash);
Now I, being the administrator of this server and having complete access to the source code and password table, plus administrative tools can simply reset a user's password to whatever I would like, but for the sake of understanding security better, I am curious how to go about doing this the way a hacker would. I have a program called cain & abel which brute forces against a specific hash algorithm, but how would I do something like taking each attemped password, sha1 ing it, concatenate it to the (known) salt, and sha1 ing it again? This seems like it would be very simple to do, but I have never programmed in a language like C++ and I presume that is what is necessary.
EDIT:
I should specify the following:
This is an offline brute-force attack.
I have the database full of hashes and their respective salts.
The salts are per user, but I only want to attack one user's password at a time.
Specifically, I am asking how to brute force a password using a custom series of hashing algorithms, such as the one I showed above:
pseudocode:
$hash = sha1( 'password' );
$salt = '3Sf';
$hash = sha1( $salt.$hash);
I presume whatever method would be used to do this could also be used to brute force a password hashed with a known algorithm such as:
$hash = sha1( 'password' );
$salt = '3Sf';
for($i; $i<1000; $i++){
$hash = sha1( $salt.$hash);
}
So I am not specifically asking for the CODE to do the first thing, I am asking by what method I can run a brute force program against a customized hashing algorithm like the 2 I have listed above.
NOTE: I am in no way stating I am likely to encounter this situation, but I would like to know how it is done.
To my knowledge, no broadly available hash-cracking tool supports this functionality.
However, as you said, it would be extremely simple to write a program to crack the hashes given enough time.
If your attacker already knows your way of computing the salted hashes, we can safely assume he either has access to your DB (which would necessarily store the salts as well), a dump of it or access to plaintext communication between your app and a client.
To then crack the hashes, he would simply replicate your sha1($salt . $hash) function and start feeding common passwords to it. This would save time compared to purely brute forcing all possible combinations. He'd take the $salt from you DB and compare the result of the hashed-salted-hashed password to the salted hash stored in the same DB.
If the resulting hashes match, the password has been "cracked".
In general, using individual salts for each user is a good idea as it increases the time to crack an entire DB table of passwords exponentially. Instead of running a wordlist against a single hashing function with a single salt, he'll have to run the entire wordlist against every single hashed PW in your database.
That said, if the attacker is far enough into your system to actually acquire the hashes / salts it would be much easier for him to alter your code to send him plain text copies of credentials of users logging in in the first place.
Much too simplistic of a question. There are a lot of things to consider and way too many to hit on in one post but here are a few. 1) Does the hacker have the password store? If so, brute force attacks can be more successful because there are no other mitigators to keep the attack from proceeding. 2) Has the hacker been able to penetrate your system and reveal your salt/hashing systems? This will make it much easier for the brute force attack especially if 1 is true. 3) If 1 and 2 are false, are there mitigation systems in place to prevent/slow a brute force assault such as locking an account after a number of incorrect passwords in a row etc.
By and large, phishing and especially spear phishing are much more likely to succeed on a well maintained/secured system than brute force, though brute force is a great way to achieve DOS as well. There is a whole discipline based on this topic and soooooo much more to consider.
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