Debian Locks Out Developers
daria42 wrote in with an update to an earlier story about a Debian server that was compromised. He explains: "The Debian GNU/Linux project has discovered a compromised developer account was used to gain access to a server compromised this week. A local kernel vulnerability was then used to gain root access. Due to this, a number of developers with weak passwords have been locked out of their system accounts." To be fair, they'll most likely be let in once everything's back to normal. Of course, they'll probably need to set safer passwords too.
I guess this means that there are a lot of ubuntu users out there who are vunerable right now... how long for the patch?
Also, the article seems to be a little out. Shouldn't it be just 2.6.12 -> 2.6.17.4 as this includes 2.6.16 -> 2.6.16.24
Does it go on forever?
Have you thought this through? The point of regularly changing passwords is so that if a blackhat gets a password then it will only work for a limited time. If a blackhat can find the password "KmcJxusUc822" that was stored on a old broken backup harddrive found in a flee market, it won't be of any use to him if the password is changed monthly, *unless* the user uses incremental passwords. If the backup is one year old then the blackhat only has to guess a password around "KmcJxusUc834".
By running cracking tools against them, of course.
It's a public-key encryption system.
You generate a public/private key pair on your computer. You send the public key to the admin of the server, who installs it for your account on that server. When you try to connect, instead of passing along a password, you pass along a "login" message digitally signed/encrypted using your private key. The server can use your public key to verify that it's really you.
It's like PGP/GnuPG, but for user accounts instead of people.
John the Ripper most likely. Great tool - recovered the root password for a SGI box a friend bought on eBay in less than a second (your password may vary.)
The search space for a 1024-bit private key isn't as big as for a symetric key of that size. It's still better than a password though, and there's nothing restricting it to 1024 bits.
I rarely criticize things I don't care about.
I use Kee pass for storing the random passwords. The database is secure enough, and I only have to remember one password (well, I keep a few fast to type insecure passwords for use in things I don't care about, like one-time-use stuff.)
N64ÞEm¢f:]&ÆqfNP8Q_- is a nice password, and not THAT hard to memorize... N64 ALT+0222 capital-E m ALT+5787 f:]& ALT+5778 qf capital-N capital-P 8 capital-Q _-
It would probably take me about half an hour to memorize it, a few days of use to get perfectly consistent. Writing it down until then works, then destroy the paper it was written down on.
After that, all my passwords can be random junk and I'll be able to memorize them.
Also, keepass allows attatching files. One could have many password databases, each embedded into another. wheeeeeee
Not a sentence!
Cracking passwords when you have access to the non-reversible hashed versions of the passwords (aka "/etc/shadow") can be trivially easy on modern hardware, when using a tool such as John the Ripper, or, if you have a lot of spare harddrive space (and RAM), RainbowCrack. If this box was using md5 hashes (most likely), JTR on modern hardware can easily crack 8,000+ passwords a second, which, when combined with advanced password guessing techniques, will most likely find weak passwords within an hour or two.
And so we go, on with our lives
We know the truth, but prefer lies
Lies are simple, simple is bliss
Please alter my pants as fashion dictates.
The story title is a bit misleading; only accounts with bad passwords or those who (for $DEITY knows what reason) appeared to have private keys on gluck were locked out. Everyone who has sane passwords and/or only uses ssh keys to log into their accounts still have access.
Of course, anyone who could actually log in already knows this because they've read d-d-a (or have already logged in.) In any event, rather troubling that the PRCTL bug managed to find its way into the kernel, but good that the intrusion was caught relatively quickly and neutralized.
http://www.donarmstrong.com
Well, the parumutaions change depending on whether or not the program displays that you are correct with the first password. Cracking a 16 digit password would square the time it took to crack, where two eight digit passwords separatly would simply double it.
If a nation expects to be ignorant and free, in a state of civilization, it expects what never was and never will be.-TJ
A couple more:
Protocol 2
PermitEmptyPasswords no
LoginGraceTime 2m
MaxAuthTries 6
And it's always a good idea to restrict SSH access to trusted IP addresses in
python>>> q="'";s='q="%c";s=%c%s%c;print s%%(q,q,s,q)';print s%(q,q,s,q)
No, actually the mistake was all mine.
I hereby declare to be a complete tool, and my only defense is the fact that the amount of caffeine in my blood was not enough to compensate my sleepy state.
A 8 character password has C^8 possible combinations (where C is the number of available characters). A 16 character password has C^16 possible combinations... and C^16 == (C^8)^2.
So doubling the length squares the search space, and you were correct.
As a Slashdot discussion grows longer, the probability of an analogy involving cars approaches one.
A password generating algorithm that doesn't use acronyms like "AES", "PRNG", etc. doesn't meet the definition of "strong". The problem with your method is that it's extremely vulnerable to frequency analysis. For example, the results will almost never contain the substrings "zq", "xg", "uz". That doesn't necessarily make your passwords week, but they definitely fall short of being cryptographically random.
A better approach is to use something like "pwgen -s" to create one really good password. Then, use that as the encryption password on a database storing all your other computer-generated passwords. I couldn't give you my online banking password if you put a gun to my head since I only saw it once: when I was copying-and-pasting the output of pwgen into my webbrowser.
Dewey, what part of this looks like authorities should be involved?