Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Honeywords in SQL Server Expand / Collapse
Author
Message
Posted Thursday, May 16, 2013 10:18 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, September 11, 2014 10:25 AM
Points: 148, Visits: 148
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


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 11:08 AM
Points: 31,371, Visits: 15,839
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


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Friday, December 19, 2014 11:21 AM
Points: 1,793, Visits: 5,044
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.
Post #1453674
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse