May 15, 2013 at 10:22 pm
Comments posted to this topic are about the item Honeywords in SQL Server
May 16, 2013 at 1:53 am
Honeypot accounts may be easier to implement
May 16, 2013 at 2:00 am
Hmmm. Interesting idea.
Maybe combine it with Honey Accounts: as well as the real accounts, you have lot of accounts which have insufficient privilege to do anything interesting, and audit successful logins as well as failed ones on those accounts. Give some of those accounts nice tempting names.
Tom
May 16, 2013 at 4:22 am
Jo Pattyn (5/16/2013)
Honeypot accounts may be easier to implement
That is probably true, but if you have a billion users, you can probably only afford to have a few honeypot accounts, and therefore it is a one-in-a-million chance that you will detect a particular hack attempt. The way that this was described, (I read about it yesterday on another site) you use circa ten honey-passwords for each account, which doesn't use much space, and you have a ten-to-one chance (in your favour) of detecting a hacking attempt.
May 16, 2013 at 7:12 am
Rename sa, create a new "sa" account, track all attempts to log into it?
One would think that most hackers that are attempting to hack a SQL server would try the sa account first. Heck I can't even count how many times as a consultant I would come in and log right in with sa and no password (ok so that has been a while...).
May 16, 2013 at 7:56 am
Anders Pedersen (5/16/2013)
Rename sa, create a new "sa" account, track all attempts to log into it?
I think the intention was to apply this at a rather larger scale than just SQL server!
May 16, 2013 at 8:07 am
If the production server should only be accessable by an admin or service accounts, then there is no reason why login attempts should be routinely failing with invalid account name or password. The same goes for 'invalid object' errors. That would imply ad-hoc logins and querying, so on the first failed attempt, an email should be sent to the administrators. Perhaps on investigation it would be explained by a misconfigured application change or a buggy stored procedure, but in any event, it's something out of the ordinary and worth looking into right away.
There could also be honeypot tables. For example, the DBA could create tables with enticing names like [Employee_Salary] or [Customer_CreditCard] and then place an audit event with email notifications. Even an internal hacker who gains access with a proper account name and password could fall for that one.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 16, 2013 at 9:19 am
Eric M Russell (5/16/2013)
...There could also be honeypot tables. For example, the DBA could create tables with enticing names like [Employee_Salary] or [Customer_CreditCard] and then place an audit event with email notifications. Even an internal hacker who gains access with a proper account name and password could fall for that one.
Oohh, I like that. A great idea.
May 16, 2013 at 9:40 am
Steve Jones - SSC Editor (5/16/2013)
Eric M Russell (5/16/2013)
...There could also be honeypot tables. For example, the DBA could create tables with enticing names like [Employee_Salary] or [Customer_CreditCard] and then place an audit event with email notifications. Even an internal hacker who gains access with a proper account name and password could fall for that one.
Oohh, I like that. A great idea.
Taking it another step forward, there could even be honeypot data. For example, a corporation concerned about hackers (or internal employees) stealing confidential financial information could populate tables with bogus revenue, sales projections, or executive salaries.
Or the banks could post bogus credit card numbers on the web. When someone attempts to make a purchase using one of these account numbers, it would alert local police. Theives may even come to conclusion that databases of "stolen" account numbers are not worth the risk.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 16, 2013 at 9:50 am
Two factor authentication would be nice, perhaps even some sort of approval process enabled that required multiple approvals for some changes.[/Quote]
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.
May 16, 2013 at 10:18 am
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.
May 16, 2013 at 10:39 am
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.[/Quote]
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.
May 16, 2013 at 10:46 am
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply