SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Honeywords in SQL Server


Honeywords in SQL Server

Author
Message
david.morton
david.morton
SSC-Enthusiastic
SSC-Enthusiastic (171 reputation)SSC-Enthusiastic (171 reputation)SSC-Enthusiastic (171 reputation)SSC-Enthusiastic (171 reputation)SSC-Enthusiastic (171 reputation)SSC-Enthusiastic (171 reputation)SSC-Enthusiastic (171 reputation)SSC-Enthusiastic (171 reputation)

Group: General Forum Members
Points: 171 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.
Steve Jones
Steve Jones
SSC Guru
SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)

Group: Administrators
Points: 65199 Visits: 19118
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
My Blog: www.voiceofthedba.com
Eric M Russell
Eric M Russell
SSChampion
SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)

Group: General Forum Members
Points: 12670 Visits: 10693
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."
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search