You assume that the threat was made known to anyone who was technically competent. The email probably just included a screen shot of Gentoo booting up.
If my spouse is doing business in Mexico anywhere outside of one of those "don't walk more than 50 yards from the hotel" resorts, I'm better off finding a new one anyway. Maybe I'll go to Mexico and kidnap one.
Seconded. I disowned my mother when she got a Verizon cell phone, and shot my dog when he peed on a Verizon service riser. I'll replace every electronic device I own with Sony products and get "Microsoft Forever" tattooed on a banner under Bill Gate's life-sized head shot (and some roses, I guess - gotta have roses) on my back before I ever do a bit of business with any of the Verizon companies again.
That's right - the only humorous posts which should be allowed on my Slashdot are humorous posts that absolutely everyone finds unanimously humorous. That should be a moderation queue for any attempt at humor - subtle, obvious, sarcastic, or unintentional, and the post should not be allowed on the main page until everyone has viewed it and agreed that it is, in fact, amusing enough for public consumption. There's no room here for any sort of disagreement in what is and isn't funny, as this discussion of random news is serious business.
Well, that's what I was referring to when I said "hopefully it's hard". But really, brute force isn't the only way. Let's say this fingerprint reader is the way you start authenticating to a bunch of web sites. All I have to do is find one which I can compromise, either through weak encryption or some vulnerability on either end (man in the middle, phishing, whatever). Once your fingerprint's string has been compromised, then what? You plan to change it?:)
I'm curious (as is izomiac, I'd imagine) - where did you come up with 128 bits for fingerprint reader data? A few seconds of Google didn't get me anything.
Rather than just look at Google - is there a patch to GNU libc which makes crypt() accept bcrypt as a hashing algorithm? 'Cause that'd be pretty much what would have to happen for it to be a viable option for Linux system passwords...
The post I responded to mentioned that it's bad if a company loses a big file with thousands of passwords because you could just work for a little while and find a few. You are 100% correct that a single password is not harder to crack, but salting makes it harder to break all (or even several) since you have to repeat the same average effort for each individual instead of doing the whole file in one shot.
So, the point I was trying to make was that you can't just start computing hashes and hope you land on one from the file; you are limited to just the ones with the same salt - which should be only a couple in a given file. You have to target a specific account rather than just calculating hashes and hoping you land on one that matches.:)
And technically, the salt only makes it a little harder to precompute hashes; the old DES crypt, for example, is now fairly easy to calculate all possible values with all possible salts. You can probably just download the file if you don't have a couple of recent computers at home to dedicate for a couple of days.;)
Not moot, just delayed a little longer until computers get fast enough to break SHA-512 faster.
Fun note: Ubuntu uses SHA512 by default, and has for a while. In/etc/login.defs, the number of SHA rounds is also configurable; it defaults to 5000, but can be set up to 999,999,999 if you really want to slow logins down.:)
The tool referenced: http://www.golubev.com/files/ighashgpu/readme.htm says it can do ~3.6 million attempts per second for MD5 passwords, which many "average" admins still consider to be the state of the art replacement for DES. That makes it pretty quick to brute force a short password.
Oh, and the DES algorithm your HP-UX and AIX systems still use is really hard. And don't forget the BigCrypt (two or three DES iterations!) the TCB implementation on that HPUX system, oh my!
It's a problem outside of Windows, because computers have gotten faster since the late 90s when we realized that NTLM was too simple.:)
Your fingerprint is read by a consumer-side device, converted to a string of some sort, and sent to a server to verify. The hacker now just has to brute-force that string instead, and send it in response to "what's your fingerprint". Hopefully that's hard, but maybe it's not.
I though the use of delay loops went away with computer games of the 80's. Besides, as soon as a faster computer comes out, the old algorithm is useless for security, and the new algorithm is so slow that it's useless on the old computers. Same problem that led to the move from DES to salted DES to MD5 to SHA512 to... You're chasing your tail with key stretching.
The article is talking about how easy it is to brute-force a password. The reason the letters were chosen don't matter one bit; if you pick 7 characters because your name is bendovr or because you LikeToEatPizzaNakedAtMidnight, it is still trivial to guess every possible 7 character combination. Sure, the probably matches will be chosen first, but if you're talking about the difference between 5 and 28 seconds with a kick-ass GPU or two, who cares?
The current solutions are to pick longer passwords and to use more complicated hashing algorithms - and to make sure the hashes are secured to begin with, which is why/etc/shadow exists.:)
Yes, games use GPUs for people who aren't black-hats.
But, to your other question, how do you propose that we integrate multi-factor authentication in a portable way that actually works with all the things people need to authenticate against? You need an interface to get to that second factor somehow, and that second factor needs to be secure and pretty standard. It's a really hard problem to solve in a universal way, which is the main reason we still use PIN/password kind of things pretty much exclusively.
If every password uses a unique salt, then it becomes substantially more difficult. You essentially have $number_of_salts different algorithms you have to attempt in that case. Say the passwords are MD5 encrypted (which should be SHA512 in modern times, but let's ignore that). If you're brute forcing, you try each possible string once, and compare the hash of "aaa" against all of the hashes. But wait, now you toss in the 0-8 character salt (selecting from the set [a-zA-Z0-9_] that GNU libc supports; you now have to recalculate that md5 hash for every possible salt in the file. There's what, around 64^8 possible salts, which might be randomly selected or might be sequentially selected based on the other salts in the shadow file; either way, you don't have to calculate the hash once - you have to calculate it once for every different salt. That's a whole lot of calculations for each possible iteration in your brute force attack - and is why salted passwords are a Real Good Thing.
Let's look at some alternative alternative math: that 3.3 billion passwords/sec were at http://www.golubev.com/files/ighashgpu/readme.htm. Note that this is the speed for cracking MD5 passwords, which were deemed "almost ready to crack" a few years ago. Modern Linux systems all support sha256 and sha512 hashing; given that this tool is 1/3 slower for sha1 (aka "sha160"), one can guess that current sha2 (sha256/sha512) algorithms will be slower. It's also worth nothing that the algorithms supported by the tool mentioned in the article are *all* not supposed to be used as of 2009: http://csrc.nist.gov/groups/ST/hash/policy.html; the tool doesn't currently even support the sha2 algorithms. The common algorithms which are currently supported (ie, md5) have been breakable in fractions of a second through rainbow tables for years anyway - which was NIST's point, IIRC.
I suppose I'll also note that the Ubuntu 11.04 system I'm typing this upon right now is configured out of the box to use sha512 hashing in/etc/shadow (check/etc/login.defs on most Linux systems, look for password strings which start with $6$). Assuming the use of PAM for anything important and passwords stored either in root-only shadow file or in an LDAP directory which does compare-only access or server-side hashing, and a secure transport such as current TLS, then this is a non-issue on a Unix system which hasn't already been compromised. It'd be easier and probably more effective, as usual, to socially engineer a password (or otherwise gain access through the human interface weak point) than to get password hashes and break them.
First, thanks for a rational response to a topic you probably find marginally offensive, given your implied role with the Gentoo project.
I reject the idea that packagers are only responsible for making a package compile with minimal changes. Someone needs to be looking at the whole picture instead of focusing on their small slice of the world, and packagers are in the best place to do that (or at least play a huge role in that). I see that constantly in my day job (enterprise security) where every business area only cares about their piece of the pie, completely ignoring (or just not understanding) how their slice fits in to the whole picture. It's frustrating there, and frustrating in my OS.:)
I thought it somewhat contextually obvious that the "data inside" referred to the primary data source for portage, but yes, "bundles of source code and supporting files known as ebuilds".:)
I don't know what you're talking about with the reference to Scientific Linux (RedHat-based) and SuSE (which is, I suppose, SuSE-based); neither of those are debian-derived; both are RPM-based distros that I dislike.:) Debian and Ubuntu are common Debian distros. Here's the first useful Google result related to apt-build - https://nigibox.wordpress.com/2009/10/01/apt-build-%E2%80%94-optimize-your-debian/ - I'd suggest reading about it more, and about apt in general. At a high level, you can pin package versions from multiple repositories with apt, and you can rebuild everything from just one package and its dependencies up to the whole darned system with apt-build. Portage is a cool system, but if you look in-depth, the apt/dpkg world has a very comparable feature set. It does not suck nearly as much as rpm (even with yum/yast wrapped around it), or other package systems like pkgtool, or whatever it was that Stampede used (it's been a while since an i686-native distro was a novel idea), or HP's POS swtool, or AIX's lpp format, or...
Debian Stable isn't known for up-to-date code, as that branch's goal is somewhat obviously "stability". You can use "unstable" and get very up-to-date code, or you can use a derivative like Ubuntu for a pretty good compromise in between.:)
I will wholeheartedly embrace the idea that many (in fact, most) Gentoo problems are user problems. But there are still way more problems than acceptable which are issues which maintainers should have caught. I'm willing to grant that it's way hard to catch the problems I find unacceptable - between upstream changes and downstream Stupid Users(R), there are just too many variables for anyone to manage. Ultimately it comes down to the distro user's personal level of tolerance; my tolerance is pretty low, but just slightly higher than Gentoo could previously reach. Other people have different tolerance levels, and I don't think they're stupid for using Gentoo. Heck, I support RHEL during my day job, and I *hate* the way RedHat does things (both in the distro and as a business) - but I don't for a moment think my employer is stupid for wanting to use RHEL. I endorse the variety of distros and people's choice to use the distro which best suits their needs. I do think that Gentoo fills a pretty narrow niche, though, and that it's a poor choice for environments where stability or reliability are the top priorities. Based on previous experience which may no longer be completely valid - Gentoo only fills a stability need well through the use of a mostly-binary install, and at that point, Gentoo's primary benefits are very much diminished.
I do like the Gentoo philosophy, though, and I've heard that things have turned around after the initial turmoil after Daniel Robbins left. But honestly, Gentoo offers me zero benefits over Ubuntu at this point. I get acceptable stability, and a very flexible build environment in the rare case that I need that. The only decen
You can launch vnc via [x]inetd and have it connect to localhost via XDMCP, using PAM for authentication at the chooser you ultimately get. Don't bother with VNC passwords, and that frees you from having to give people specific port assignments. You (generally, depending on how you set it up) lose the disconnected support - but a setup like that is a real nice way to get around the difficulty (and cost) in setting up Windows X Servers; the VNC clients are all comparatively simple to set up and secure.:) And VNC generally uses less bandwidth than X11, at the expense of more processes running on the Unix side.
So, there's been a bug for years, but you just hit it recently? Sounds like a new bug.;)
(I'll pretend I haven't seen all sorts of problems with NFS root on different Ubuntu releases for the last several years; the bug seems to relate to the way the mounting and detecting-of-mounting works; my name's probably in a few of the bugtracker threads)
Slashdot Mirror
You assume that the threat was made known to anyone who was technically competent. The email probably just included a screen shot of Gentoo booting up.
If my spouse is doing business in Mexico anywhere outside of one of those "don't walk more than 50 yards from the hotel" resorts, I'm better off finding a new one anyway. Maybe I'll go to Mexico and kidnap one.
Seconded. I disowned my mother when she got a Verizon cell phone, and shot my dog when he peed on a Verizon service riser. I'll replace every electronic device I own with Sony products and get "Microsoft Forever" tattooed on a banner under Bill Gate's life-sized head shot (and some roses, I guess - gotta have roses) on my back before I ever do a bit of business with any of the Verizon companies again.
All of our interns would like to come work wherever you work.
No one that stupid has ever created a /. account. I'm pretty sure someone created Jon Katz's account for him., BTW.
That's right - the only humorous posts which should be allowed on my Slashdot are humorous posts that absolutely everyone finds unanimously humorous. That should be a moderation queue for any attempt at humor - subtle, obvious, sarcastic, or unintentional, and the post should not be allowed on the main page until everyone has viewed it and agreed that it is, in fact, amusing enough for public consumption. There's no room here for any sort of disagreement in what is and isn't funny, as this discussion of random news is serious business.
Well, that's what I was referring to when I said "hopefully it's hard". But really, brute force isn't the only way. Let's say this fingerprint reader is the way you start authenticating to a bunch of web sites. All I have to do is find one which I can compromise, either through weak encryption or some vulnerability on either end (man in the middle, phishing, whatever). Once your fingerprint's string has been compromised, then what? You plan to change it? :)
I'm curious (as is izomiac, I'd imagine) - where did you come up with 128 bits for fingerprint reader data? A few seconds of Google didn't get me anything.
Rather than just look at Google - is there a patch to GNU libc which makes crypt() accept bcrypt as a hashing algorithm? 'Cause that'd be pretty much what would have to happen for it to be a viable option for Linux system passwords...
The post I responded to mentioned that it's bad if a company loses a big file with thousands of passwords because you could just work for a little while and find a few. You are 100% correct that a single password is not harder to crack, but salting makes it harder to break all (or even several) since you have to repeat the same average effort for each individual instead of doing the whole file in one shot.
So, the point I was trying to make was that you can't just start computing hashes and hope you land on one from the file; you are limited to just the ones with the same salt - which should be only a couple in a given file. You have to target a specific account rather than just calculating hashes and hoping you land on one that matches. :)
And technically, the salt only makes it a little harder to precompute hashes; the old DES crypt, for example, is now fairly easy to calculate all possible values with all possible salts. You can probably just download the file if you don't have a couple of recent computers at home to dedicate for a couple of days. ;)
Not moot, just delayed a little longer until computers get fast enough to break SHA-512 faster.
Fun note: Ubuntu uses SHA512 by default, and has for a while. In /etc/login.defs, the number of SHA rounds is also configurable; it defaults to 5000, but can be set up to 999,999,999 if you really want to slow logins down. :)
The tool referenced:
http://www.golubev.com/files/ighashgpu/readme.htm
says it can do ~3.6 million attempts per second for MD5 passwords, which many "average" admins still consider to be the state of the art replacement for DES. That makes it pretty quick to brute force a short password.
Yeah, the MD5 algorithm your old RedHat Linux box probably uses sure takes this tool a long time to calculate.
http://www.golubev.com/files/ighashgpu/readme.htm
Oh, wait...
Oh, and the DES algorithm your HP-UX and AIX systems still use is really hard. And don't forget the BigCrypt (two or three DES iterations!) the TCB implementation on that HPUX system, oh my!
It's a problem outside of Windows, because computers have gotten faster since the late 90s when we realized that NTLM was too simple. :)
Your fingerprint is read by a consumer-side device, converted to a string of some sort, and sent to a server to verify. The hacker now just has to brute-force that string instead, and send it in response to "what's your fingerprint". Hopefully that's hard, but maybe it's not.
Actually, the tool linked also cracks MD5 passwords. And SHA1. And a number of permutations:
http://www.golubev.com/files/ighashgpu/readme.htm
I though the use of delay loops went away with computer games of the 80's. Besides, as soon as a faster computer comes out, the old algorithm is useless for security, and the new algorithm is so slow that it's useless on the old computers. Same problem that led to the move from DES to salted DES to MD5 to SHA512 to... You're chasing your tail with key stretching.
I think that's why I stopped using MD5 passwords in favor of SHA512 several years ago. ;)
The article is talking about how easy it is to brute-force a password. The reason the letters were chosen don't matter one bit; if you pick 7 characters because your name is bendovr or because you LikeToEatPizzaNakedAtMidnight, it is still trivial to guess every possible 7 character combination. Sure, the probably matches will be chosen first, but if you're talking about the difference between 5 and 28 seconds with a kick-ass GPU or two, who cares?
The current solutions are to pick longer passwords and to use more complicated hashing algorithms - and to make sure the hashes are secured to begin with, which is why /etc/shadow exists. :)
Yes, games use GPUs for people who aren't black-hats.
But, to your other question, how do you propose that we integrate multi-factor authentication in a portable way that actually works with all the things people need to authenticate against? You need an interface to get to that second factor somehow, and that second factor needs to be secure and pretty standard. It's a really hard problem to solve in a universal way, which is the main reason we still use PIN/password kind of things pretty much exclusively.
If every password uses a unique salt, then it becomes substantially more difficult. You essentially have $number_of_salts different algorithms you have to attempt in that case. Say the passwords are MD5 encrypted (which should be SHA512 in modern times, but let's ignore that). If you're brute forcing, you try each possible string once, and compare the hash of "aaa" against all of the hashes. But wait, now you toss in the 0-8 character salt (selecting from the set [a-zA-Z0-9_] that GNU libc supports; you now have to recalculate that md5 hash for every possible salt in the file. There's what, around 64^8 possible salts, which might be randomly selected or might be sequentially selected based on the other salts in the shadow file; either way, you don't have to calculate the hash once - you have to calculate it once for every different salt. That's a whole lot of calculations for each possible iteration in your brute force attack - and is why salted passwords are a Real Good Thing.
Unless some bone-head forgot to limit access to the password field in LDAP to compare-only, or forgot to turn on encryption on the LDAP transport. ;)
Let's look at some alternative alternative math: that 3.3 billion passwords/sec were at http://www.golubev.com/files/ighashgpu/readme.htm. Note that this is the speed for cracking MD5 passwords, which were deemed "almost ready to crack" a few years ago. Modern Linux systems all support sha256 and sha512 hashing; given that this tool is 1/3 slower for sha1 (aka "sha160"), one can guess that current sha2 (sha256/sha512) algorithms will be slower. It's also worth nothing that the algorithms supported by the tool mentioned in the article are *all* not supposed to be used as of 2009: http://csrc.nist.gov/groups/ST/hash/policy.html; the tool doesn't currently even support the sha2 algorithms. The common algorithms which are currently supported (ie, md5) have been breakable in fractions of a second through rainbow tables for years anyway - which was NIST's point, IIRC.
I suppose I'll also note that the Ubuntu 11.04 system I'm typing this upon right now is configured out of the box to use sha512 hashing in /etc/shadow (check /etc/login.defs on most Linux systems, look for password strings which start with $6$). Assuming the use of PAM for anything important and passwords stored either in root-only shadow file or in an LDAP directory which does compare-only access or server-side hashing, and a secure transport such as current TLS, then this is a non-issue on a Unix system which hasn't already been compromised. It'd be easier and probably more effective, as usual, to socially engineer a password (or otherwise gain access through the human interface weak point) than to get password hashes and break them.
First, thanks for a rational response to a topic you probably find marginally offensive, given your implied role with the Gentoo project.
I reject the idea that packagers are only responsible for making a package compile with minimal changes. Someone needs to be looking at the whole picture instead of focusing on their small slice of the world, and packagers are in the best place to do that (or at least play a huge role in that). I see that constantly in my day job (enterprise security) where every business area only cares about their piece of the pie, completely ignoring (or just not understanding) how their slice fits in to the whole picture. It's frustrating there, and frustrating in my OS. :)
I thought it somewhat contextually obvious that the "data inside" referred to the primary data source for portage, but yes, "bundles of source code and supporting files known as ebuilds". :)
I don't know what you're talking about with the reference to Scientific Linux (RedHat-based) and SuSE (which is, I suppose, SuSE-based); neither of those are debian-derived; both are RPM-based distros that I dislike. :) Debian and Ubuntu are common Debian distros. Here's the first useful Google result related to apt-build - https://nigibox.wordpress.com/2009/10/01/apt-build-%E2%80%94-optimize-your-debian/ - I'd suggest reading about it more, and about apt in general. At a high level, you can pin package versions from multiple repositories with apt, and you can rebuild everything from just one package and its dependencies up to the whole darned system with apt-build. Portage is a cool system, but if you look in-depth, the apt/dpkg world has a very comparable feature set. It does not suck nearly as much as rpm (even with yum/yast wrapped around it), or other package systems like pkgtool, or whatever it was that Stampede used (it's been a while since an i686-native distro was a novel idea), or HP's POS swtool, or AIX's lpp format, or...
Debian Stable isn't known for up-to-date code, as that branch's goal is somewhat obviously "stability". You can use "unstable" and get very up-to-date code, or you can use a derivative like Ubuntu for a pretty good compromise in between. :)
I will wholeheartedly embrace the idea that many (in fact, most) Gentoo problems are user problems. But there are still way more problems than acceptable which are issues which maintainers should have caught. I'm willing to grant that it's way hard to catch the problems I find unacceptable - between upstream changes and downstream Stupid Users(R), there are just too many variables for anyone to manage. Ultimately it comes down to the distro user's personal level of tolerance; my tolerance is pretty low, but just slightly higher than Gentoo could previously reach. Other people have different tolerance levels, and I don't think they're stupid for using Gentoo. Heck, I support RHEL during my day job, and I *hate* the way RedHat does things (both in the distro and as a business) - but I don't for a moment think my employer is stupid for wanting to use RHEL. I endorse the variety of distros and people's choice to use the distro which best suits their needs. I do think that Gentoo fills a pretty narrow niche, though, and that it's a poor choice for environments where stability or reliability are the top priorities. Based on previous experience which may no longer be completely valid - Gentoo only fills a stability need well through the use of a mostly-binary install, and at that point, Gentoo's primary benefits are very much diminished.
I do like the Gentoo philosophy, though, and I've heard that things have turned around after the initial turmoil after Daniel Robbins left. But honestly, Gentoo offers me zero benefits over Ubuntu at this point. I get acceptable stability, and a very flexible build environment in the rare case that I need that. The only decen
FYI:
You can launch vnc via [x]inetd and have it connect to localhost via XDMCP, using PAM for authentication at the chooser you ultimately get. Don't bother with VNC passwords, and that frees you from having to give people specific port assignments. You (generally, depending on how you set it up) lose the disconnected support - but a setup like that is a real nice way to get around the difficulty (and cost) in setting up Windows X Servers; the VNC clients are all comparatively simple to set up and secure. :) And VNC generally uses less bandwidth than X11, at the expense of more processes running on the Unix side.
No, the second contender would be vim. The emacs option doesn't come up until you've dismissed both vi and vim. :)
So, there's been a bug for years, but you just hit it recently? Sounds like a new bug. ;)
(I'll pretend I haven't seen all sorts of problems with NFS root on different Ubuntu releases for the last several years; the bug seems to relate to the way the mounting and detecting-of-mounting works; my name's probably in a few of the bugtracker threads)