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


Honeywords in SQL Server


Honeywords in SQL Server

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)

Group: Administrators
Points: 140719 Visits: 19415
Comments posted to this topic are about the item Honeywords in SQL Server

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
Jo Pattyn
Jo Pattyn
SSCertifiable
SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)

Group: General Forum Members
Points: 6833 Visits: 10009
Honeypot accounts may be easier to implement
Tom Thomson
Tom Thomson
One Orange Chip
One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)

Group: General Forum Members
Points: 25254 Visits: 12488
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

mike brockington
mike brockington
SSC Veteran
SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)

Group: General Forum Members
Points: 250 Visits: 245
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.

Throw away your pocket calculators; visit www.calcResult.com


Anders Pedersen
Anders Pedersen
Hall of Fame
Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)

Group: General Forum Members
Points: 3130 Visits: 902
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...).
mike brockington
mike brockington
SSC Veteran
SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)SSC Veteran (250 reputation)

Group: General Forum Members
Points: 250 Visits: 245
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!

Throw away your pocket calculators; visit www.calcResult.com


Eric M Russell
Eric M Russell
One Orange Chip
One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)

Group: General Forum Members
Points: 27952 Visits: 11481
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.


"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."
Steve Jones
Steve Jones
SSC Guru
SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)SSC Guru (140K reputation)

Group: Administrators
Points: 140719 Visits: 19415
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.

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
One Orange Chip
One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)

Group: General Forum Members
Points: 27952 Visits: 11481
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.


"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."
Rob Ashton
Rob Ashton
SSC-Addicted
SSC-Addicted (427 reputation)SSC-Addicted (427 reputation)SSC-Addicted (427 reputation)SSC-Addicted (427 reputation)SSC-Addicted (427 reputation)SSC-Addicted (427 reputation)SSC-Addicted (427 reputation)SSC-Addicted (427 reputation)

Group: General Forum Members
Points: 427 Visits: 133
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.
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