joncle at googlemail
Jun 17, 2012, 5:07 PM
Post #11 of 18
On Sun, 17 Jun 2012 23:17:37 +0000, Steven D'Aprano wrote:
Re: Is that safe to use ramdom.random() for key to encrypt?
[In reply to]
> On Mon, 18 Jun 2012 08:41:57 +1000, Chris Angelico wrote:
>> On Mon, Jun 18, 2012 at 3:06 AM, Rafael Dur├ín Casta├▒eda
>> <rafadurancastaneda [at] gmail> wrote:
>>> The language Python includes a SystemRandom class that obtains
>>> cryptographic grade random bits from /dev/urandom on a Unix-like
>>> system, including Linux and Mac OS X, while on Windows it uses
>> /dev/urandom isn't actually cryptographically secure; it promises not
>> to block, even if it has insufficient entropy. But in your instance...
> Correct. /dev/random is meant to be used for long-lasting
> cryptographically-significant uses, such as keys. urandom is not.
>>> Do you think is secure enough for token generation? (40 chars long
>>> tokens are used for password reset links in a website, there isn't any
>>> special security concern for the web).
>> ... it probably is fine, since password reset tokens don't need to be
>> as secure as encryption keys (if anyone _does_ figure out how to
>> predict your password resets, all they'll be able to do is lock people
>> out of their accounts one by one, not snoop on them all unbeknownst,
>> and you'll be able to see log entries showing the resets - you DO log
>> them, right?). In fact, you could probably get away with something
>> pretty trivial there, like a SHA1 of the current timestamp, the user
>> name, and the user's current password hash. The chances that anybody
>> would be able to exploit that are fairly low, given that you're not a
>> bank or other high-profile target.
> If I were an identity thief, I would *love* low-profile targets. Even
> though the payoff would be reduced, the cost would be reduced even more:
> - they tend to be complacent, even more so than high-profile targets;
> - they tend to be smaller, with fewer resources for security;
> - mandatory disclosure laws tend not to apply to them;
> - they don't tend to have the resources to look for anomalous usage
> patterns, if they even cared enough to want to.
> If there was a Facebook-like website that wasn't Facebook, but still
> with multiple tens of thousands of users, I reckon a cracker who didn't
> vandalise people's accounts could steal private data from it for *years*
> before anyone noticed, and months or years more before they did
> something about it.
>  And very likely a Facebook-like website that *was* Facebook. I
> reckon the odds are about 50:50 that FB would prefer to keep a breach
> secret than risk the bad publicity by fixing it.
I'm reminded of:
There's also one where it's pointed out it's easier to brute force a
person who has the code, than brute force the computer. [but can't find
that one at the moment]