Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase ««12

Honeywords in SQL Server Expand / Collapse
Posted Thursday, May 16, 2013 10:18 AM


Group: General Forum Members
Last Login: Tuesday, December 29, 2015 8:27 AM
Points: 153, Visits: 155
A step in the right direction. How about adding additional checking to ensure the user is who they say they are. For instance. SQL Server run in a corporate environment behind a firewall could lock down accounts using constantly changing passkeys that exist only for a short duration and are placed in a random folder that exists for a short duration. The verification process would look at the location of the passkey as well as the passkey. If the user logging in is not on the local network, then the passkey was hijacked and the logon attempt would fail and access would be denied. This also assumes that the validation process will pass the encrypted location of the passkey to the client and the client must have access that location and that removes the outside world from the picture. There would be a lot of protocol happening during this whole process, using the previous passkey to decrypt the location so that the client can send a validation request to the server in a timely manner so that the server won't reject the login attempt.

For the outside world, a similar process but using a slightly different approach - which I haven't really concentrated on yet!

There has been a lot of conversation covering this topic falling under different ideas ranging from loginless access to network security. I think three random 128 bit encrypted passkeys that change with every login would be the good deterrent. That would mean a multipass verification process. To continue to the next level of the login process, the previous part must pass and so forth. The question is how many levels of validation is enough while also realizing that at some point in this process we will have the weakest link and that would be in the client application.

Just my two cents worth.
Post #1453658
Posted Thursday, May 16, 2013 10:39 AM



Group: Administrators
Last Login: Today @ 1:04 PM
Points: 34,375, Visits: 18,596
Rob Ashton (5/16/2013)
Two factor authentication would be nice, perhaps even some sort of approval process enabled that required multiple approvals for some changes.

It's funny that you mentioned this Steve, I'm actually in the middle of putting a demo system for exactly those two things at the minute. Once it's done, and if I get approval from above, I can put a post together for fellow SSC'ers to read about.

Excellent, would love an article on this. I've seen a few people suggest setting sa with a long password, with 2 people having a part of it, but that limits you to a specific password and specific (pairs of) people.

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1453669
Posted Thursday, May 16, 2013 10:46 AM

SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 2:03 PM
Points: 4,136, Visits: 9,239
Of course, if your database accepts only network domain logins, then all this fancy authentication would be handled by Active Directory, not by SQL Server. Users login to the network using rotating passwords, dongles, etc.

However, SQL Server can also do additional things like verify machine or IP address using login triggers.

"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
Post #1453674
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse