Schneier on Security

Roger • November 6, 2005 8:06 PM

@DavidG:

“In short, standard password advice already overcomes all these weaknesses”
Will it? For example, you can’t enforce a policy for people to use mixed-case,
because even if you did, it would instantly turn it to upper case first.

Note that my sentence continued “…with perhaps the caveat that Oracle password minimum lengths need to be about 1~2 characters longer than you might otherwise expect.” Provided your passwords are not dictionary words (which is part of standard advice), then increasing the length by 2 characters typically increases the strength by more than that lost by smashing case. In the optimal case of passwords chosen randomly from the whole available character set, an 8 character password chosen from all 96 printable characters has about 2^^53 possibilities while a 9 character one omitting lower case has 2^^55, so even one more character more than compensates for the case smashing [1]. Alarmingly, many sites continue to permit 6 character passwords which should have gone out of style in about 1980. Upgrading them to minimum 8 gives you about 18 more bits which is lots more than lost by case smashing.

Anyway, some additional advice if you’re still worried:
a) Obviously it is pointless to insist on mixed case so instead insist that passwords include letters, digits and/or punctuation marks, preferably randomly chosen from all three.
b) Making user names unique per database will greatly reduce the effects of the weak salts. One way to do this might be to prepend the database name, so that instead of user ‘david’ we have user ‘acme-test-david’. Scripts couldn’t care less about this, while better interactive tools cache the user names used for each database (and the passwords too, if you permit them) so it isn’t much hassle to humans. However it means that the weak Oracle salt is now highly likely to actually be globally unique (except for system level accounts which you can’t change).
c) Conversely, system accounts should either be disabled (if not required) or given very strong passwords (at least 14 characters randomly selected from all available).
d) Try to ensure that the username/password combination is at least 17 bytes. This will increase the attacker’s time requirements by only 25%, but can be done very cheaply if you use long usernames, which is easily achieved through point b) above. Actually by employing point b) above plus 10 character passwords you can easily get the combination to 25 bytes or more, which will increase the opponent’s time requirements by 75%. (Every 4 bytes gives another 25% increment.) Not a huge gain but useful and cheap.
e) Better yet, give all your users Password Safe so they don’t need to remember their passwords, and have a password minimum of 20 randomly chosen characters for all accounts.

Although the easiest way to get into most Oracle systems is to log in as system/manager….

Yes, absolutely. It is distressing to see the number of “Unbreakable (TM)” production grade Oracle databases in large companies which use default passwords (incredibly even including the password “change_on_install”), blank passwords, or passwords equal to the username (which is often the same as a product or project name). In one place I worked, the strongest Oracle password on site, at least the strongest I came across, was a 5 character dictionary word with the ‘i’ changed to ‘1’. The DBAs generally justify this on the grounds of the network admin’s rock solid routing security. Um, yeah, right.

Footnote:
1. Of course 2^^55 attacks are now feasible for very resourceful opponents (c.f. the distributed DES cracking contest) so I now actually consider the minimum to be 10 characters, unless significant stretching is involved. Due to Moore’s law we can presume this minimum will continue to increase at the rate of about 1 character per decade, so I would recommend that all new systems include a stretching mechanism which is capable of gradually upgrading the stretching factor. That is, each password record in addition to the salt and the actual hash includes (say) a 32 bit unsigned integer which says what stretching factor was used, and the password change mechanism checks to see what stretching factor should be used for new hashes. In this way you can increase the stretching to keep pace with your hardware so that logins take roughly constant time as you upgrade the hardware. Since presumably Moore’s law affects attackers and defenders about equally, such a mechanism roughly negates Moore’s law and means that 1970’s grade passwords will remain suitable forever. The required entropy of a password is then determined solely by the ratio between acceptable login delay (say, 1 second for ordinary human operated accounts) and the expected cracking time (say, 1 year for low grade accounts). A ratio of 1 second to 1 year gives an entropy limit of log_2( 2 years/1 s) = 25.9. A single case alphanumeric password hits this with about 5 characters; choosing from all printable characters we would only require 4. Admin accounts could be made slower (say, 5 s) for better protection, while script accounts would need to be faster, but can have much stronger passwords to compensate.