5 ms·

Thanks for posting the link. I found this particular tidbit especially useful: "The first is to create 'canary' accounts. Create accounts that have e-mail addr

by smoody 18y ago

Thanks for posting the link. I found this particular tidbit especially useful: "The first is to create 'canary' accounts. Create accounts that have e-mail addresses, like "something-really-long-xyz-123@gmail.com". This account is not going to get any spam e-mail. When it does get its first spam, you'll know that it came from your database."

slackerIII 18y ago
Agreed -- I thought that was a good idea (useful + cheap to implement + low false positive rate). One thing I've also debated about before is whether to use a per-site or a per-user salt for passwords. From this article, it sounds like a per-site hash is enough to defeat the rainbow table services.
- iseff 18y ago
  Not sure I agree. It seems true that a per-site hash would be enough to defeat _just_ the rainbow table services, but I wouldn't want to have the hacker be able find one password and then be able to distinguish what the salt is for everyone. I would rather have this mitigated by knowing that even if the hacker does brute-force one password, he still won't know the salt for anyone else.
  - slackerIII 18y ago
    Yeah, I don't think I made the point I meant to make. Previously, I was under the (silly) assumption that folks who were trying to brute force passwords were running their own rainbow set ups, generating them as necessary based on whatever per-site hash was being used. But the fact that services exist for cracking this sort of thing implies that there are plenty of sites that aren't using salts at all, and by using a per-site salt, you are not the softest target. None of this matters if someone is trying to crack your site in particular, but sometimes you just have to be faster than the slowest gazelle in the herd.
  - tptacek 18y ago
    I'm just going to remind you that if you are talking about your code and you are using words like "salt" and "rainbow table" you have already lost.
- streety 18y ago
  Why not use both a per-site and a per-user salt?
tptacek 18y ago
The problem with this advice is that it is not particularly useful. In the event that your canary account receives a spam message, you will have gained one piece of data: that at some point in the months since you installed the account, it is likely that someone exploited a problem that exposed a table column in your database. Now what? You don't know what the bug was. You don't know how far-reaching the damage is. You don't know when the event occurred. There is, in fact, almost nothing actionable about this information at all. You might be telling yourself two things: * That, upon learning of the possible breach, you will lock down the security of your code and your site. Of course, think for two more seconds and realize this is ass-backwards; if you can reasonably lock down your site, you might as well do it before you burn your whole database. * That, upon learning of the breach, you can get all your users to change passwords. Which, of course, you will never do, because you will be taking an enormous reputational hit over circumstantial evidence, and for the purposes of seeding your database with a couple thousand new passwords for the same attacker to steal. People like this "canary" and "honey token" stuff because it's fun. But it's not valuable.
- slackerIII 18y ago
  If I called you and said, "Hey, would you like me to tell you your site has been cracked?", would you really say "no"? I would argue that the cost of adding a canary is similar to the amount of time that phone call would take. I'm guessing that after that call, you'd go through your logs and attempt to find out how the site was cracked. Then, if you find some anomalous behavior, you might be able to isolate the component that was being exploited and fix it. Maybe you wouldn't find it, but maybe you would.
  - tptacek 18y ago
    What's your point? Sure. Set up a canary account. It won't hurt you. But the only way it will help is if your monitoring regime is already so good that it works with or without the canary.
- mattmaroon 18y ago
  What if you automatically created a new canary every day with the date in it? Something like something-really-long-xyz-yyyy-mm-dd@yourdomain.com. Then you could find out exactly when your database was stolen. If all canaries up to 2009-01-01 were spammed, and later ones weren't, you'd know they dumped your db on New Year's Day. Not sure how much that would help either though.

by smoody 18y ago

slackerIII 18y ago

Agreed -- I thought that was a good idea (useful + cheap to implement + low false positive rate). One thing I've also debated about before is whether to use a per-site or a per-user salt for passwords. From this article, it sounds like a per-site hash is enough to defeat the rainbow table services.

iseff 18y ago
Not sure I agree. It seems true that a per-site hash would be enough to defeat _just_ the rainbow table services, but I wouldn't want to have the hacker be able find one password and then be able to distinguish what the salt is for everyone. I would rather have this mitigated by knowing that even if the hacker does brute-force one password, he still won't know the salt for anyone else.
- slackerIII 18y ago
  Yeah, I don't think I made the point I meant to make. Previously, I was under the (silly) assumption that folks who were trying to brute force passwords were running their own rainbow set ups, generating them as necessary based on whatever per-site hash was being used. But the fact that services exist for cracking this sort of thing implies that there are plenty of sites that aren't using salts at all, and by using a per-site salt, you are not the softest target. None of this matters if someone is trying to crack your site in particular, but sometimes you just have to be faster than the slowest gazelle in the herd.
- tptacek 18y ago
  I'm just going to remind you that if you are talking about your code and you are using words like "salt" and "rainbow table" you have already lost.
streety 18y ago
Why not use both a per-site and a per-user salt?

tptacek 18y ago

The problem with this advice is that it is not particularly useful. In the event that your canary account receives a spam message, you will have gained one piece of data: that at some point in the months since you installed the account, it is likely that someone exploited a problem that exposed a table column in your database. Now what? You don't know what the bug was. You don't know how far-reaching the damage is. You don't know when the event occurred. There is, in fact, almost nothing actionable about this information at all. You might be telling yourself two things: * That, upon learning of the possible breach, you will lock down the security of your code and your site. Of course, think for two more seconds and realize this is ass-backwards; if you can reasonably lock down your site, you might as well do it before you burn your whole database. * That, upon learning of the breach, you can get all your users to change passwords. Which, of course, you will never do, because you will be taking an enormous reputational hit over circumstantial evidence, and for the purposes of seeding your database with a couple thousand new passwords for the same attacker to steal. People like this "canary" and "honey token" stuff because it's fun. But it's not valuable.

slackerIII 18y ago
If I called you and said, "Hey, would you like me to tell you your site has been cracked?", would you really say "no"? I would argue that the cost of adding a canary is similar to the amount of time that phone call would take. I'm guessing that after that call, you'd go through your logs and attempt to find out how the site was cracked. Then, if you find some anomalous behavior, you might be able to isolate the component that was being exploited and fix it. Maybe you wouldn't find it, but maybe you would.
- tptacek 18y ago
  What's your point? Sure. Set up a canary account. It won't hurt you. But the only way it will help is if your monitoring regime is already so good that it works with or without the canary.
mattmaroon 18y ago
What if you automatically created a new canary every day with the date in it? Something like something-really-long-xyz-yyyy-mm-dd@yourdomain.com. Then you could find out exactly when your database was stolen. If all canaries up to 2009-01-01 were spammed, and later ones weren't, you'd know they dumped your db on New Year's Day. Not sure how much that would help either though.