On Tue, Feb 03, 2015 at 12:14:54AM -0600, Rob Landley wrote: > >> A) I was just going to use the encryption the first entry (presumably > >> root) had, given a choice. (Although again, if the android mechanism > >> doesn't let you get a user list... presumably they still have uid 0 > >> though.) > > > > This sounds unreliable; in hardened environments you might not be able > > to get another user's password hash. > > In which case I fault back to the first entry in the list because I know > it's there? > > Newer algorithms may not be supported by the toolchain/libc they're > building against, and if they're not we don't get a compile-time warning > about it. Right now sha256 is recent enough (added to glibc 2007) that > we can probably expect it to be there, but if sha3 gets added, how do we > know if we've got it?
That's why I suggested trying them in sequence of strength -- at runtime. Just have an array of known "setting" string forms (this is tiny) and iterate over it until crypt doesn't spit out an error. > > Simply > > trying different "setting" strings for each known algorithm in > > decreasing order of strength and using the first one that works seems > > a lot smarter. > > Which means my code has to know about "decreasing order of strength", > and I need to change it when new algorithms are introduced, and then > change it more for random libc forks that have their own experimental > stuff because Red Hat wants to differentiate itself to justify the > Enterprise per-seat cost... You don't need to change it for Red Hat. Just include in the list all known setting strings, and the ones that aren't supported won't be used. The current order is something like: bcrypt, sha512, sha256, enhanced des, md5, classic des > I suppose I can do a menuconfig option for it, but ugh. 95% of > everybody's going to go with the default there anyway, this is way too > esoteric to ask most people to make decisions about. Pretty much anyone who does know/care/understand wants the strongest crypt their libc/tools supports, and those who don't know/care/understand should have the most secure option chosen for them by default. > > >> B) des salt is 4096 possible entries, _anything_ else lets you use more > >> salt. > > > > md5crypt has been EOL'd by its author and really should not be used as > > a default for anything new. See: > > > > http://phk.freebsd.dk/sagas/md5crypt_eol.html > > I actually go by: > > http://valerieaurora.org/hash.html > > Which basically says "anything but sh3 is already toast, and that one's > just too new to have much data on yet". (See the table at the end for > explanations of the stages. That's the best part.) No, that's unrelated to crypt. It's about a single application of the underlying hash functions, not the KDF's used in crypt. Note that "password hash" or "KFD" is not mentioned anywhere on that page because that's not what it's about. > My assumption is that if people can _get_ your hash, you've probably > already lost. Hash checking is an embarassingly parallelizeable problem Yes and no. From an individual standpoint defending your own accounts, this is largely true. On the other hand, from a site-wide perspective and general internet health perspective where you're concerned about things like the portion of users whose accounts can be efficiently compromised, the KDF used makes a big difference. The extent to which this matters for unix login accounts is of course open to discussion. Ideally security-conscious users are only using ssh public key auth anyway and have passwords disabled. So from that standpoint this is all more relevant to other places passwords are used, which is mostly outside the scope of the toybox utilities. On the other hand, for sites that still ARE using password-based unix account logins, I would think you'd want to mitigate the risks. > It doesn't matter what hash you're using if passwords being input have > less bits than the keyspace. The set of "keys humans press in sequence > without 2 factor authentication" is pretty darn attackable. My keyboard > has something like 47 shiftable keys on it, plus space and tab. That's > 96^length, so anything less than 10 chars long is under 2^64 likely > combinations _before_ you do statistical analysis of the likelihood of > symbol occurrence to sort your keyspace traversal and so on. (For > reference, distributed.net brute forced a 64 bit key using volunteered > CPU time over a dozen years ago.) That's why KDF's are designed to be expensive to compute. > Me, I assume any box with cracked permissions to read /etc/shadow has a > keylogger installed anyway. But I'm not a security expert... So, like you say about non-experts in licensing trying to make/choose licenses.... > So yes if you think sh3 should be the default when nobody specifies, I'm > all for it. Let me know when that shows up in crypt() and what number it > gets assigned, the man page for crypt in ubuntu 14.04 hasn't got it and > google isn't being helpful either. sh3 (Keccak) itself would not be a KDF. You can build a KDF using it, and in fact there were some such proposals in the PHC (https://password-hashing.net/) if I'm not mistaken. Rich _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
