On 02/02/2015 02:03 PM, Rich Felker wrote: > On Sun, Feb 01, 2015 at 11:59:45PM -0600, Rob Landley wrote: >> >> >> On 02/01/2015 10:19 PM, Rich Felker wrote: >>> On Mon, Feb 02, 2015 at 10:33:24AM +0900, 김혜진 wrote: >>>> Hello. I share a patch of su command. >> ... >>> md5 is not better and probably worse than des. You should be using >>> bcrypt if the system supports it and otherwise sha256, sha512, or the >>> enhanced des support some systems have. These could be tried as >>> sequential fallbacks.
My objection to des wasn't really the algorithm, but that the hash is not in the $#$salt format everything else uses. (If they'd made it $0$salt it probably wouldn't have come up.) Having the default be a special case rubs me the wrong way, it means theoretically common code isn't getting regularly tested. (Whereas _not_ supporting des at all, eh no big loss because it _is_ obsolete. People will send us bug reports if they actually use it and hit something.) >> 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? > (Of course such environments may > require modifications/tweaks to the passwd utility but it would be > nice to keep the amount of modification required minimal.) Pilot error isn't my problem, they can write their own from scratch. I do not, under normal circumstances, care about people creating something that is not unix. (Wake me when they ship their first billion units.) In the case of android, we don't currently get a password from _anybody_ so it's probably a moot point. (As far as I know, the only thing the system currently uses a password for is the lock screen. Even the vendor unlock stuff is dialing magic numbers with #!#! around them, a "secret" shared by thousands of people worldwide and thus not hard to get ahold of.) I'm pragmatic about serving the needs of big existing user bases. My reaction to the possibility of people in the future doing something stupid is to wait for them to notice what they tried doesn't work and start complaining about it. > 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... That's encoding policy, and I'd _really_ rather not. 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. >> 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.) My assumption is that if people can _get_ your hash, you've probably already lost. Hash checking is an embarassingly parallelizeable problem in an age of amazon's elastic compute cloud having multiple competitors and people looking for something to repurpose mining gpu stacks for when the bitcoin money laundering protocol fad ends. (I expect the feds want to keep bitcoin around as long as possible, it makes catching extra-stupid drug trafficers so _easy_ because people inexplicably think it provides anonymity.) Lots of salt at least makes precomputing take more storage (although the DOD commissioned a 2.5 terabyte ramdisk in 2004 so you have to use quite a bit to actually annoy the feds). 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.) 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 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. > Rich Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
