this may sound non sense, actually in may application I use to store password string in DB by computing to hash using SHA512Managed, I am writing a utility using which an admin can send mails to users using that EmailAddress and Password, but I can't pass that coputed value as a password to SMTP. is there any way to solve this?
Or a better cryptogarphy way?
Or any way to send mail in this condition?
Thanx
You cant, SHA512 I believe is not possible to be decrypted, which is why it is used.
All you can do is keep some form of data on your users aka, secret questions, and they must match them and then it will send them a new password.
Any properly encrypted password is not abled to be decrypted
You should NOT be using OR sending your users password, or even a simple hash of that, for that matter.
If you want to enable password reset, you should hand the users a TOKEN (which is NOT the hash of anyone's password). This token should be separately stored in a table and should have a set expiry.
You can use any kind of cryptographic hash (SHA512 is just fine) to 'encode' special information.
--- I fully missed what you meant by 'I cannot...as a password to SMTP'
If you need the original password of your users to even send mail, than - well that is twisted. Perhaps you could elaborate/explain this part
SHA-512 is a one-way hash, meaning you can't take the hash value and determine what string/value was used to generate that hash. Technically, there can be an infinite number of strings/values that would generate the same hash.
If you want to be able to get the value back, you should use encryption, not hashing.
Related
i seemed Confused what i need to do.it a normal login scenario.i storing hashed value of password in database.[Please dont consider What Hashing Function i Using ].At The Login Time
user inputs his plain Text Password.Now what i needed to Do is hash this password ,pass it web service Then My DataBase Need to Compare Two Hashed Values.Now what i dont know is.
When i hash the Password at login time with salt.Is it still the same value i get or Something else
Can My dataBase(Sql server 2008) Able to Compare Two Hashed Values if Not then what i need to do.There is no need of Get the Password From Database.
Passing Hashed Password over Web services needs Extra Consideration of Security?
i need to Handle Password Recovery also.and can i use encryption/decryption algorithms here.
Please Suggest What i need to Do .
To increase security, it would be better to use a random salt.
The way i use to protect password while storing in the SQL server is that:
Create salt from the password, then generate hash with concatenation
of user name and password..
It will make the salt dependent on password and user name. If you are recovering your password then if credentials are correct then you are able to reset the password.
can i use encryption/decryption algorithms
??
As per your encryption method, Create your own algorithm to encrypt and decrypt the password with salt using the .net encryption libraries.
You have to save salt to database too.
in Authentication, Get salt, hashed inputted password with salt, compare with the hased value in database. All of these can reside in C# code.
You can't get original password from hashed value. You can generate a random password and force customer to change password in next login.
So I think hashed value is safe to transfer online. For a site Adminstrator, even he has access to database, he still doesn't know the password of customer.
I am trying to create a secure password login screen in c#.Right now i have just created the login screen and I am able to read the username and password from the database.But which i have designed does not have an encrypted password. Can any one help me out how to write a query to generate encrypted password and store the encrypted password value in a separate field.Thanks in advance.
Consider hashing the password that you currently store. SQL can hash a password as follows:
DECLARE #HashThisPassword nvarchar(4000);
SELECT #HashThisPassword = CONVERT(nvarchar(4000),'dslfdkjLK85kldhnv$n000#knf');
SELECT HashBytes('SHA1', #HashThisPassword);
... But SQL shouldn't even need to do this. You should hash the password as soon as your C# application receives it, and then only ever pass the hashed password into SQL to be saved. When checking if the user has provided the correct password for login, compare the hashes.
Your best bet is one way encryption.
What happens in this scenario is the user selects/is given a password. When that password is stored in the database it passes thorugh this one way encryption before it is stored. (You'll be doing this in your c# code)
Then when the user logs in, the entered password passes through this same one way encryption before it is compared with the password in the database.
This ensures that if a hacker gets into the database, it will be difficult to learn the password because they would have to determine the encryption type, and then devise a way to un-encrypt it which to my understanding is difficult at best, impossible at worst.
Here is a link to some code that may help. One Way Encryption
You don't want to do the encryption in sql itself, because if a hacker DOES access your database, they will be able to simply look at the procedure/function that you are using to do the encryption and they will have a much easier time.
And you don't want to store the password in the database unencrypted as well...
Your best bet is to write some code to read the password, encrypt it, and update the record, then all you have to do is continue to use the same encryption type and salt.
The c# cryptography library is very easy to use.
I have a RESTful API containing a URI of /UserService/Register. /UserService/Register takes an XML request such as:
<UserRegistrationRequest>
<Password>password</Password>
<Profile>
<User>
<UserName>username</UserName>
</User>
</Profile>
</UserRegistrationRequest>
I have the following questions given the above scenario:
Is there a way (using C# and .Net 3.5+) of enforcing/validating that clients calling Register are passing a hashed password rather than plaintext? Is leaving the choice of hashing algorithm to be used to the client a good idea?
We could provide a second URI of /UserService/ComputePasswordHash which the client would call before calling /UserService/Register. This has the benefit of ensuring that each password is hashed using the same algorithm. Is there a mechanism within REST to ensure that a client has called one URI before calling another?
Hope I've explained myself ok.
Many thanks in advance for any help.
Passing a hashed password in a REST service isn't more secure than clear password. If the password gets sniffed it doesn't matter if it's hashed or not, it can be used.
Best thing to do is hash the password on server and accept secure connections only (SSL/https)
It's a bad idea to let clients hash passwords themselves. Generally speaking, hashing only password is not very secure: a random salt has to be appended to the password so that same passwords will produce different hash values. With that, client will have to generate salt (preferably using cryptographically secure algorithm), compute hash of a resulting sting (using compliant implementation of a well-known hashing algorithm) and then send three pieces of information back to the server:
Hashing algorithm name
Salt
Hashed password
What if server doesn't have an implementation of a particular hashing algorithm? What if client hashing algorithm produces different results compared to servers' one?
Now back to your questions:
You can enforce password to be sent in Base64 encoding and then check if this string, converted back to byte array, contains non-printable characters, which are very likely to appear in a hash value. Though they might not be there
You can include some kind of token to a response from ComputePasswordHash and then require your clients to pass this token back to Register
Hashing would not be good idea . A more better would be either use SSL or use a subset of it youself using public key encryption api in .NET framework.
You will expose function GetPublicKey() which will return public key through which user will encrypt his password and send it to you. Then use your private key to decrypt it. And check if it correct. RSA or Elliptic curve base public key alogs are very good. Just use 1024bit.
UPDATE:
check this example as well also this from msdn
in my current C# windows application password has been stored in plain text which is obviously not good. so i just want to know what is the best way to encrypt the password and stored into SQL Server. I have read that using hash+salt is better. but i feel "EncryptByPassPhrase","DecryptByPassPhrase" new feature in sql 2005 is better to use because you are handling everything from SQL Server itself and i suppose it uses triple DES. can somebody suggest is it good to use it ?
Do you need to have access to the original password, or are you just going to try and compare an entered password against one in the database?
If you need access to the original password, then you are going to have to use an encryption algorithm instead of a hash algorithm.
If all you're doing is storing a password in the database so that you can check it later against a known input value, then a hash with a salt will work.
Remember that when the client is sending the credentials across to be validated, that you don't want to be sending the password in clear text!
A hash & salt is the way to go, because its impossible to retrieve the original password from it. If you encrypt then decrypt the password, the plaintext password is retrievable so its not the best.
I agree it makes sense to have the encryption all in 1 place. However if you separate the key from the data (key in the c# code, data in the db), that will increase security. Also, Sql Server uses a master key when encrypting, which means if you need to restore the data to a new server, you will have trouble restoring the data.
This all comes down to key management and how you want to do this.
As with most questions the best answer depends on the context of your situation. There is no good solution.
Some options:
Leave the password in plain text or reversably encrypt. Use SQLServer facilities to encrypt important fields at the RDBMS level or use similiar encryption functions and hope that MS has implemented reasonable key management and the keys are reasonably secure for your purposes. In practice all encryption does is collapse storage of a whole lot of little secrets into storage of one big secret.. It might make the problem more managable but the problem itself never goes away.
Irreversably "Encrypt" the password using a hashing algorithm or some form of crypt(). Depending on the attack vectors available this method may not provide much in the way of actual improvment of security over plaintext storage.
. Use of hashed passwords limits your options in terms of selection of a secure authentication algorithm. With this approach you will likely end up sending plain texts or other material that is no better over a transport (regardless of if unbound encryption is used or not) this can be a substantial risk from a trust POV.
. Succeptable to offline dictionary attack if hashes are stolen recovery of some portion of passwords should be outright assumed if they have any value to an attacker.
. In some cases knowledge of the password hash can be just as bad as knowing the password in terms of system access.
If you are certain that you will never use a hashed scheme to authenticate (like HTTP Digest Auth), hashed password is more secure. To avoid rainbow table attack, please use a nonce (or salt). I would use HMAC-SHA1 and use the nonce as the key. They key must be stored with the password.
Otherwise, you will have to store encrypted password because hashed password can't work with authentication involving hashes. For encryption, I have following suggestions,
Don't store the key in DB, don't hardcode it either. Store it some other secure place, like using DPAPI on Windows.
Make sure you have a key version so you can rotate the key to comply with certain standards.
I am not familiar with the encryption in SQLServer. Make sure it has a random Initial Vector. You can check this by encrypting same password twice, it should yield different ciphertext. If no random IV, don't use it, just encrypt it in your application.
I'm in a bit of a strange dilema. Please bear with me as I try to explain it!
I'm using forms authentication and am storing additional user information in another table (referenced UserID from Forms Auth, encrypted SSN, Salt value). When users register to the site, I ask SSN, DOB and LName and verify against our system before they create an account. I want to determine if that SSN has an account associated with it in forms authentication. Since the SSN is encrypted with a salt value, I can't do a lookup without looking at each row.
I only want 1 user account per SSN. Using a salt value disrupts this.
The way I see it, the only way around this is to use a common encryption algorithm for the SSN. When the user types it in, I apply the same encrypt algorythm and see if there is a value match in the user extended properties table.
Is this secure enough?
Rather than use the same salt value, generate the salt based on the other user information so that it can be reconstructed. Thus, you can regenerate the salt once the user applies, and you can generate the expected hash and get the job done in a single query.
If you wish to encrypt (not hash) the SSN value, it is not a good practice to store the key in the same table as Natso has pointed out. This is fraught with danger, since keys are not to be stored with the data they protect - if an attacker manages to obtain a dump of your database, he would be able to decrypt the encrypted contents, since the key is stored along-side.
The application should obtain the key from a secure key store which could then be used to encrypt/decrypt the information. This way, you could continue to store sensitive information in the database thereby protecting your information, and apply a different mechanism (usually file-system security) to protect your key store.
This is of course, assuming that your requirement is to store data in a secure manner in the database, and recover the same at a later point time. However, if you do not the data to be recoverable once it has passed through an algorithm, you should explore the use of hashes.
Use the same salt every time. Then you can compare the encrypted values.