Password encryption: Best Practice ?
-
L.S.
A while ago i posted a warning against the encrypt function and added a recommandation for the pwdencrypt function. Because of my curious nature, it's not a gift, i started reading several security/password encryption related papers. Some of them explained the vulnerabilities of the pwdencrypt function. So what to do now ? Of course i could enhance the middleware and use windows encryption techniques, or buy some component to do it for me. But what is the common practice, are there any good i-net sources of it? I'd appreciate some good links on this subject.
Regards,
Richard
-
Probably your best bet is to encrypt in the application. If you don't use SSL or Multiprotocol (w/ Encryption), the password will go across the wire in plaintext. Even if you do use either of these measures to encrypt the network traffic, a sysadmin with Profiler is going to be able to see the password come across in plaintext. Even if Profiler blocks the output view due to the name of the stored procedure (try viewing an sp_password call), a sysadmin always has the option of trying to capture using DBCC INPUTBUFFER(). Keep in mind that keeping the key safe will become an issue when you move the encryption to the application, however.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
We're using pwdencrypt now to store some passwords for an application. Its a step up from plain text storage! We'll swap out for some tougher code later on probably, but for now its good enough - forces us to deal with one way encryption, resetting passwords, etc.
Andy
-
I've upgraded my tables by storing passwords generated by the pwdencrypt function in stead of encrypt. If anyone's intrested i'd be happy to sent the SQL-script for it.
The script decodes the 'old' passwords en encodes them using the new function. Afterwards the script changes table definitions and updates.
For a more permanent solution we're, as adviced, going to use application encryption (middleware). Impact analysis will start in the near future 😉
Thanx for your help.
-
You have to assess your vulnerability and detemine how big a deal is this. Is someone more likely to social engineer a pwd for your system than try to crack the passwords?
Are they likely to crack the NT/2000 pwds and connect that way?
Be aware of snake oil and spending too many resources on something that isn't worth it. Someone will ALWAYS find a awy to crack what you've done. The question is: Is it worth it to them and can they do it in a reasonable amoutn of time to where the information still matters?
I'm not sure how big a deal this is, especially if you force password changes every so often.
Steve Jones
-
I agree with that. We added the ability to force a password reset required on next login, require password change every 90 days, three fails in 30 minutes we disable the account, account not accessed in more than 90 days gets disabled. If password lost we reset to a random string, require reset on login. Not a lot of work to get all that really, not much more to swap out the encryption if/when we get around to it.
Andy
-
There are enough free implementations of various protocols that have been deemed secure. Plus, there's always CryptoAPI. So I agree with Steve to not spend too much. You should be able to implement at the application fairly easily and cheaply.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
Wow, someone agrees with me!
Use some secure protocols if you need them, definitely the stuff accepted in the industry is the best choice. Just be aware of what you are trying to do.
Steve Jones
-
I agree with you most of the time, Steve!
Most of the time when I don't I'm wrong.K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
I hardly ever agree with him, and thats to keep him honest!
Andy
-
I have to agree there. However if you do use any encryption from the client a few easy things to rememeber is this.
1 Do not use easily recognized names for variables such as password, encpass or anything that may hint at the functionality of the variable. A hacker looks for this with Memory spyware.
2 If you can use one way encryption meaning the password is also the keyword for the encryption against itself making knowing the password a requirement.
3 If you must have two way encryption and put the keyword into the application use unusual character combinations making it a not so obvious key and will look more like the code. VB, C, and most other programming languages do not encypt constant values so avoid them for keywords. And when saving open the exe in notepad and see if you can easily find it.
4 Use a highly dependable encryption such as DES or better 3DES.
5 Even with as much obviscation as possible do not use a password save option in your application as this makes it easier to steal. Just because you see ****** doesn't mean there isn't a way to sneak a peek see the following link for example methodology. http://www.codeguru.com/ieprogram/SPwdSpy.html
6 As in the previous as soon as you are thru with a variable that is in anyway related to encryption or the password destroy the object immediately as to not leave anything traceable in memory. Or better set it to something else as though it is a standard part of the application and because it could potentially tip of a hacker playing with your app.
Finally, I do agree with Steve (me too) that don't overwork yourself on this concern as if they want it they will work their best to get at it depending on how hard it is. And a real hacker will do it for the challenge so making it hard will deter most but not all and hopefully they are just very curious and will tell you about it if they find a hole or they just don't care about the data.
Most of the time when I don't I'm wrong.Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply