Is this secure?
in [Python]
|
Prev: ANN: Leo 4.7 final released
Next: AKKA vs Python
From: Paul Rubin on 24 Feb 2010 15:09 mk <mrkafk(a)gmail.com> writes: > def rand_str_custom(n): > s = os.urandom(n) > return ''.join([chr(ord('a') + ord(x) % 26) for x in s if ord(x) < 234]) Note that simply throws away some of the chars. You have to replace them, not throw them away. > rand_str_SystemRandom_seeding > mean 3845.15384615 std dev 46.2016419186 > l 3926 1.75 std devs away from mean > y 3916 1.53 std devs away from mean .... What do you think you're measuring here? Yes, if you're doing 1000's of draws from a distribution, you'd expect a few of them to be 1.75 sigma from the mean. Since there are 26 letters, you'd expect a multinomial distribution which you can test for with the multinomial test or some approximation from the article: http://en.wikipedia.org/wiki/Multinomial_test I wish I knew more statistics than I do, since there is probably some more familiar statistical test (e.g. the T-test) that you can use as the number of trials gets large, since each bin of the multinomial distribution should eventually start to look like a normal distribution due to the central limit theorem. Others here know a lot more about this stuff than I do, and can probably give better advice. Anyway though, the output of os.urandom should be extremely hard to distinguish from real randomness (that's the whole point of a cryptographic PRNG).
From: Michael Rudolf on 24 Feb 2010 16:00 Am 24.02.2010 21:06, schrieb mk: > > I just posted a comparison with calculating std deviations for various > methods - using os.urandom, SystemRandom.choice with seeding and without > seeding. I saw them > They all seem to have slightly different distributions. No they don't. Just run those tests again and you will see that you cannot put them in any order or behaviour. They are all correct now, except that you cannot seed SystemRandom, as it is *not* a PRNG (at least here, it is a wrapper for /dev/random) Regards, Michael
From: Steven D'Aprano on 24 Feb 2010 20:07 On Wed, 24 Feb 2010 18:23:17 +0100, mk wrote: > Anyway, the passwords for authorized users will be copied and pasted > from email into in the application GUI which will remember it for them, > so they will not have to remember and type them in. So to break your application's security model, all somebody has to do is use their PC and they have full access to their account? Or get hold of the copy and paste buffer? Or the application's config files? > So I have little in > the way of limitations of password length - even though in *some* cases > somebody might have to (or be ignorant enough) to retype the password > instead of pasting it in. Or your users might be sensible enough to not trust a role-your-own security model, and prefer to memorize the password than to trust that nobody will get access to their PC. > The main application will access the data using HTTP (probably), so the > main point is that an attacker is not able to guess passwords using > brute force. And why would they bother doing that when they can sniff the wire and get the passwords in plain text? You should assume your attackers are *smarter* than you, not trust them to be foolish. -- Steven
From: Paul Rubin on 24 Feb 2010 20:31 mk <mrkafk(a)gmail.com> writes: > Anyway, the passwords for authorized users will be copied and pasted > from email into in the application GUI which will remember it for > them, so they will not have to remember and type them in. It occurs to me that you don't even need to mess with letters in that case: password = os.urandom(5).encode('hex') will generate a string of 10 hex digits that you can give to the user. (That is for Python 2.x but I think it might be broken in Python 3). It might be helpful if you could say what your application does, or anyway give an idea of what its actual security requirements are. Generating and emailing someone a random password is a fairly standard method for (e.g.) web forums to verify that the person has supplied a working email address, basically as a first level spam filter. Your scheme is probably ok for that. If you're doing something with more demanding security requirements, then as mentioned before, there is a whole lot of stuff you have to pay attention to, and focusing narrowly on password generation isn't that useful.
From: mk on 25 Feb 2010 09:05
On 2010-02-25 02:07, Steven D'Aprano wrote: > On Wed, 24 Feb 2010 18:23:17 +0100, mk wrote: > >> Anyway, the passwords for authorized users will be copied and pasted >> from email into in the application GUI which will remember it for them, >> so they will not have to remember and type them in. > > So to break your application's security model, all somebody has to do is > use their PC and they have full access to their account? > > Or get hold of the copy and paste buffer? > > Or the application's config files? Yes. There's no way around this, short of forcing them to use hardware key, which is an overkill for this application. >> So I have little in >> the way of limitations of password length - even though in *some* cases >> somebody might have to (or be ignorant enough) to retype the password >> instead of pasting it in. > Or your users might be sensible enough to not trust a role-your-own > security model, and prefer to memorize the password than to trust that > nobody will get access to their PC. The app is not that critical, it's about quarterly subscription to the service, and the users will be able to reset the password anyway. If it were that critical, I'd use the hardware keys; if hardware keys are not used, once somebody gains an (unconstrained) access to the user's PC, there's not much that app developer can do. I've read somewhere a warning from PuTTY developer that even though the key is (normally) protected by the passphrase, losing even an encrypted key is quite likely to lead to its compromise. There's even some software for that on the net: http://www.neophob.com/serendipity/index.php?/archives/127-PuTTY-Private-Key-cracker.html >> The main application will access the data using HTTP (probably), so the >> main point is that an attacker is not able to guess passwords using >> brute force. > And why would they bother doing that when they can sniff the wire and get > the passwords in plain text? You should assume your attackers are > *smarter* than you, not trust them to be foolish. I should have written HTTPS. Regards, mk |