Hello, I need to keep information into a database field but I need this info to be encrypted. I need to read this info and uncrypted also. What can I do ?
Well, of course, you need to do encryption and decryption. But, I suspect you already understood this. I think you didn't really ask the question you wanted to ask.
Try asking a specific question, and I'm sure someone will have an answer for you.
Here's what I need to do : I need to keep a password and userid into a sql database. This password must be encrypted to make sure nobody can read it. When I need this password, I read the record, decrypt the password, use the password to access something and that's it.
In SQL server you can use the Windows security & not bother using your own, which will never be as secure.
If you must store passwords then I suggest you store them as encrypted MD5 hashs. This is a 1 way encryption so the actual password is never stored. I have some VB code that will create the md5 if you would like it.
Basically when you save the password you md5 it, and store the result, then when you are authenticating you md5 the user's input and compare that to the md5 you have stored.
Hope this makes some sort of sense to you, it is Friday!
Ben
----------------------------------------------
Ben O'Hara
I agree with oharab. MD5 the password. Then you just compair the users password that they've entered pushed through a MD5() function and compair. This has a number of advantages
MD5 is a constant 32 bytes for any size password from 1 character up to any length.
storing an MD5 password can not be reverse engineered. You can brute force it but that can take a long time since you don't know if the password is one character long or thousands.
If you store a password encrypted in your database then decrypting the password is pretty trival as it doesn't sound like you are talking about other security thus if someone has access to the encrypt and decrypt functions and have access to the database they have the actual password...you've just delayed them by about 5 seconds.
Drawback is that if they user forgets their password you only have the option to reset it. But this is pretty standard. Windows doesn't let admins see a user password. After they log in the system handles security with a token.
Just to continue the discussion... resetting passwords is not only pretty standard, but much preferred. If you retrieve a password for the wrong user, you give the hacker free reign on the account. If you reset a password for the wrong user, the real user knows as soon as they try to log in... often to late, but better late than never.
The downside, of course there's always a downside, is when you're using the password as the encryption key for other data... the data will be lost. It's still a great method if the data is really confendential, but just make sure to put a big disclaimer somewhere, people get peeved otherwise.
You can still have password encrypted data. Just maintain the password in the application after they log in. Then use this password to encrypt the data. Applications often do the encrypting/decrypting so it isn't that big of a deal and you get the best of both worlds. Problems comes up if the user forgets their password....never mind
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.