April 28, 2009 at 10:59 pm
Comments posted to this topic are about the item Secure Storage
April 28, 2009 at 11:20 pm
I believe the guidance is to store the key export and the password in different locations and to store both on site and off site.
How about storing the export in VARBINARY(MAX) in TDE encrypted database that has only DBA access? and then store the password in an an encrypted column, perhaps on a another SQL Instance. This would be relatively easy to automate.
This is how I had planned to implement key backup automation in SQLClue. The TDE database is easy to implement (in fact I saw an email from Connect telling me some bothersome 'nuances' of TDE are fixed in 10.5)
Finally, since many shops run two+ data centers, they could peer to peer replicate between data centers on an SSL or Server self-Certificate encrypted wire. But even without the replication, the backups of the TDE database and the encrypted column could go off site in the normal tape rotation to satisfy the requirement.
A little work to set up - not bad - but should be painless once running.
Bill Wunder
April 29, 2009 at 6:20 am
For me to memorize password, keys or anything important is next to impossible, for I am dyslexic, which also grants me the ability to process and handle algorithm fast than normal. So for me it’s about an algorithm that forms the key (or password). In my home network all passwords are something like
{Computer Name}’s {common word} #{(Month + 5) mod 12}
and are changed monthly automatically. This allow long and hard to break passwords and keys can be generated in the same fashion, But then keeping the algorithm a secret is the problem. So this is more of a method for compressing keys and passwords.
April 29, 2009 at 7:07 am
alas, real security is a pain in the rump.
One possible solution is to store the keylist history in an encrypted file, with that key only available to the few (never ONE) adminstrative individuals necessary.
The encrypted key list should be kept both on and offsite
I would not recommend a shared (partial) key system, in a disaster situation all the principals may not be available.
...
-- FORTRAN manual for Xerox Computers --
April 29, 2009 at 8:47 am
My company has created an in-house application that we use to manage passwords, keys and access to them.
all data is stored in SQL tables and is encrypted by the application.
The application records all actions taken including creation, deletion, editing, access, granting access, etc to an encrypted table in the database so it cannot be changed outside the application.
This is working very well for us.
April 29, 2009 at 9:19 am
There is no perfect solution. Either the data is completely secure, and can easily become unretrievable, or it's just barely secure, and easy to recover, or somewhere in between.
Since the compromise depends on a lot of subjective factors, I can't even offer good advice on that.
Personally, for my own secure data, I have a pattern of passwords/keys that I use. They are strong passwords, but I only rarely change them. Studies by the NSA and various universities and such have actually shown that routinely changing passwords causes a net reduction in security over time, because of the very factors you're dealing with here. The "change your password every X days" rules create the illusion of security while reducing its actuality.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 29, 2009 at 9:47 am
GSquared: Thanks so much for your comment. One of the things I can't stand is the password rotation requirements at my agency and agencies we have to deal with. I copied your comment to my boss. She agreed to try to find those studies and at least research the issue. Thanks!
April 29, 2009 at 9:51 am
We've used Password Safe to store the passwords, and the current password isn't a big deal. It's the rotation of passwords that gets confusing. I suppose you could just add a date to the name and keep all passwords there, but depending on how often you change passwords, that can be an issue.
We had an issue changing the password for Password Safe. We rarely did so since we didn't want to get caught later having an old database for which we didn't have the password.
April 29, 2009 at 10:53 am
Speaking of security here is some news posted on the BBC web site that might help in storing passwords and encryption keys and yet have the same readily available in case of need
April 29, 2009 at 10:56 am
I think two part passwords work best. The first part of the password is specific to the task. The second part is common to all tasks and is rotated regularly. I only need to worry about remembering one new password each period.
April 29, 2009 at 11:19 am
Personally, I think passwords are junk.
Encryption keys are one thing, but no person should ever need to know one. They should be system-generated and managed, and biometrics of some sort or one-time-keys should be the standards for human access. Anything that doesn't warrant that level of security, probably doesn't warrant encryption in the first place.
Currently, the technology for those things is too complex, too expensive, and too error-prone. But it's getting caught up fast.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 29, 2009 at 11:22 am
GSquared: Do you have any references to the studies you mentioned in your previous post? My boss did a search. All she could find was an NSA report suggesting that passwords be changed every 30 to 90 days. If you could easily point us in the right direction, that would be great.
Thanks.
April 29, 2009 at 11:29 am
Personally, Biometrics seems to be a bit of a waste... It's effectively a password you can't change... It works well when you can validate a body is present, but otherwise, it's just data that can be captured and used.
April 29, 2009 at 12:20 pm
I read the studies years ago (1995, if I remember correctly), so I don't have immediate access to them. Here's what I can find online at this time:
While not directly in reference to frequent changes, this is critical data:
http://www.garykessler.net/library/password.html
It also mentions the weakness of having "many passwords", which would include both concurrent and past.
Here's another article:
http://www.useit.com/alertbox/passwordsecurity.html
This one has the history of where the "change your password every X days" rule comes from, and why it's no longer applicable:
http://www.cerias.purdue.edu/site/blog/post/password-change-myths/
This is also critical of the change-your-password policy, and covers a variety of related information:
http://www.securitypark.co.uk/security_article259701.html
There's a ton of data out there about this subject. If you really want to find out how useless password logins are, including changing them every 90 days policies, download a password cracker. There are several available, some of them built for computer security specialists and some built by hackers.
I wouldn't trust one built by a hacker, unless you review the source code yourself and make sure it isn't booby trapped, but some of the security company ones are just fine.
Take a hashed password file with a couple of hundred passwords in it. Fire it through a cracker or, even better yet, a brute-force/cracker hybrid, and find out exactly how fast a password can be gotten.
Truly strong passwords, like @X15%F!^gH7*+k are impossible to crack, but they can be brute-forced. Since that one's quite long, it will take a LONG time to brute-force it. But, very, very few people could ever remember something like that, so it's inevitably going to get written on a PostIT and stuck somewhere at least moderately visible, and poof!, there goes your security.
Even if all your users have, by some miracle, the ability to memorize that kind of password, and you change it every day to something completely disrelated, using something like this:
select char(abs(checksum(newid()))%94 + 32)
from dbo.Numbers
where Number <= abs(checksum(newid()))%10 + 4
for xml path('');
All it takes is one user who responds to this e-mail:
From: System Security Officer
Re: Password Issue - HIGH PRIORITY - IMMEDIATE ACTION REQUIRED
Your randomly issued password for the day has been compromised and your account will be deactivated in one hour. To avoid this, go to this web page http://www.phish.com, and enter your username, current password, and what you want the password changed to. We will then issue your new password, as requested, and your account will be kept active.
Failure to handle this immediately will result in investigation into how your password was compromised and may result in termination.
Passwords and password-change policies are the illusion of security, not the actuality.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 29, 2009 at 12:24 pm
GSquared: Once again, a very big thank you! I've always believed that in my gut, but never had much to back it up. I'm going to show all this to my boss. Thanks!
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply