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.

Comments

Ah. balance

[Kid Zero]

That wonderful feeling of making the password hard to guess, but easy to recall.

Re:Ah. balance

[eklitzke]

The obvious alternative is to completely disable password based ssh authentication, and force everyone to use public/private key authentication. That way you don't have to worry about the strength of your users passwords.

Re:Ah. balance

[JebusIsLord]

Yeah, instead you have to worry about the locations of their memory keys!

Re:Ah. balance

[DMUTPeregrine]

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

Re:Ah. balance

[finiteSet]

That wonderful feeling of making the password hard to guess, but easy to recall.

If you are like me, it seems like almost everyday the bank or eBay is emailing about a new upgrade to the system, one that requires entering your old and new passwords, social security numbers, bank account numbers, and so on. Accordingly, I've developed some simple tips for coming up with making a hard-to-crack but easy-to-remember password:

• Short but strong: you can make the password relatively short (e.g. one character) so that it is easy to remember, but random enough to be hacker-proof. Do you really think someone would guess 'q' or 'z' ?
• Long but simple: if you are unsatisfied with the previous strategy, try this one on for size: the longer the better. So instead of 'a', you might want to use 'aaaaaaaaaaaa'. ('0000000' works, too.)
• Mirror Mirror: use your username as your password and cut the memory load in half!
• Long and strong: for the absolutely mission critical stuff, you may have to spice it up. Pair a common dictionary word, like 'dog', 'log' or 'hog' with a small digit ('1', '2', and so on), and you're golden.
• Final Notes: don't forget to recycle your old passwords and - please - keep a public list!

Re:Ah. balance

[Millenniumman]

"and starting today, all passwords must contain letters, numbers, doodles, sign language and squirrel noises."

Re:Ah. balance

[arivanov]

Ahem.

That was my first reaction as well. If you are using ssh, passwords are "the wrong idea" (TM). A password is guessable while a private key is not. That is the way it is designed.

Not that it would have helped in this case though. The attacker compromised the developer machine first and from there on compromised the server. Once you are in full control of a user machine it is game over as far as any resources it accesses are concerned.

While at it, I can also understand an admin on a large linux shell machine which still allows passwords.

Due to Theo and Co's knee jerk (hello Theo) attitude to non-OpenBSD OSes there is no way to make ssh public key authentication plug cleanly in the OS authentication chain. The reason is that ssh continues to be developed from the perspective "PAM sucks, we here do not do that". That is a purely political OpenBSD position which belongs to the realm of OpenBSD and should have nothing to do with OpenSSH. If OpenSSH is to really support linux without "OpenBSD is better TM)" being involved it will have to support PAM properly, natively, all the way and for all authentication methods including public keys. This is the way of the land.

As this is not the case yet, if you want to limit access to public key only you have to turn off PAM for ssh. Alternatively, if you manage a big machine (or network) and you need PAM you end up turning on passwords and praying.

Re:Ah. balance

[KiloByte]

Talking about openssh's security, here's a vital patch:
-PermitRootLogin yes
+PermitRootLogin no

Come on, how in the hell the first can be the default?
Is it that hard to log in first to your normal user account?

And don't start on "but having no root and using sudo is better". This is a fallacy, true only if your normal user password and the root one happen to be the same, or you have a root login available from network. Two separate passwords are always better than just one, and forcing people to type "sudo" before every line makes little sense -- quite a lot of servers have nothing to do on them for non-root (firewall, dom0, etc).

Re:Ah. balance

[corychristison]

I like nice, long, random passwords. 16+ characters. I have no problem remembering them, and I use dozens for lots of different things.

Re:Ah. balance

[zerblat]

Two separate passwords are always better than just one

Sure, having two 8 character passwords is more secure than just one 8 character password, but it's equivalent to having one 16 character password.

Re:Ah. balance

[arivanov]

With passwords you are absolutely correct. Direct root login is stupid, wrong and insecure and people leaving it should be shot.

With public key authentication for remote access + plain passwords on the machine itself you are not correct. There is no significant difference between giving direct ~/.ssh/authorized_keys based root to all the people entitled to root and giving them access with per user ~./ssh/authorized_keys and su/sudo. The simple password is inherently less secure authentication method compared to PKI and just bolting a password on the back does not do a thing. If you could tightly couple passwords with ssh PKI that will be a different matter. Same if you use one-time passwords after the login. This unfortunately requires tightly coupling all ssh authentication methods with the system ones as well as coupling ssh authentication with system authorisation.

As far as linux is concerned this requires Theo to stop his knee jerk reactions to PAM and integrate ssh and PAM properly.

By the way I agree with him that PAM sucks, but as far as having cross-platform and cross-distribution security framework we got nothing better. And no, I do not want to hear about keynote or COPS. Nobody in his sane mind wants to.

Re:Ah. balance

[Bogtha]

Due to Theo and Co's knee jerk (hello Theo) attitude to non-OpenBSD OSes there is no way to make ssh public key authentication plug cleanly in the OS authentication chain. The reason is that ssh continues to be developed from the perspective "PAM sucks, we here do not do that". That is a purely political OpenBSD position which belongs to the realm of OpenBSD and should have nothing to do with OpenSSH. If OpenSSH is to really support linux without "OpenBSD is better TM)" being involved it will have to support PAM properly, natively, all the way and for all authentication methods including public keys. This is the way of the land.

If this is so important, how come nobody has forked OpenSSH? Debian could do it. Any of the distributions could do it. You are essentially complaining that OpenBSD developers are developing OpenSSH for OpenBSD instead of the way you want them to do it. They aren't under any obligation to make dodgy (in their opinion) security decisions to please you - that would be making politicial decisions.

Re:Ah. balance

[Mark Hood]

Not in this case - if you read the summary, even.

They got in with a developer's password, then used a local exploit to get root permissions.

I.e. they didn't know (or need to know) the root password. So in this case, having two 8 character passwords was exactly as secure as having one 8 character password.

Mark

Re:Ah. balance

[BecomingLumberg]

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.

Re:Ah. balance

[aymanh]

Talking about openssh's security, here's a vital patch:
-PermitRootLogin yes
+PermitRootLogin no

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 /etc/hosts.allow.

Re:Ah. balance

[ericlondaits]

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.

Re:Ah. balance

[corychristison]

To clarify, I was being completely serious.

I've often thought of developing a script to dictionary all of my more uncommonly used passwords, but I usually have no problem remembering them.
The days that I do struggle to remember are usually my more sluggish days and I'm usually lazing around in bed or something anyway.

How I remember them is i generate one long string 25+ characters. From there I eliminate characters until it resembles a word / phrase [or random word sequence -- doesn't necessarily have to make sense as a sentence/phrase]. Then I practice typing it in a few times and I usually get it. If I struggle with it, I will go back through the process again until I find something I can remember.

Here's an example random string: UcgcDis07PtuFO19MilARdAcVdyA
I would eliminate characters until I read it as: UgcDi07PuFO19MilARdAc -- u-GC [as in university-GC] Di07 [makes me think of die-007] Puffo 19 Milar [I think if Miller Beer] dAc [duck? -- but "gangsta" style?]
No. That's not one of my passwords... just an example. ;-)

back to normal

[Coneasfast]

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.

Um. What exactly does this mean? If everything isn't back to normal, shouldn't they lock out ALL developers? That's what I would do.

Re:back to normal

[Ohreally_factor]

They're only locking out the developers who used the password "tux".

kernel exploited...

[scum-e-bag]

Schulze said the particular Linux vulnerability only
    exists in kernel versions:

• 2.6.13 up to versions before 2.6.17.4
• 2.6.16 up to versions before 2.6.16.24

    Schulze advised admins to upgrade their software if they were
    using these versions but said the current stable version of
    Debian was not affected as it run kernel 2.6.8.

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

Re:kernel exploited...

[kevlarman]

dapper drake uses the http://packages.ubuntu.com/dapper/base/linux-image -3862.6.15.xx kernel so it wouldn't be affected

Re:kernel exploited...

[scum-e-bag]

According to the ubuntu-security-announce lists, the current up to date kernel version is 2.6.15-26.44 This was released 3 days ago, before the debian server compromise was announced. According to the zdnet report, this version falls within the exploitable.

I made a mistake in my initial post, slip of finger, 2.6.13* not 2.6.12*

Re:kernel exploited...

[andersa]

Since the 2.6.16 kernels are still being maintained with regard to bugfixes, the statement is valid. The vulnerability was fixed in maintainance release 2.6.16.24 and versions of 2.6.16 from then on forward are ok.

libpam-cracklib

[dduardo]

Time to enforce a 200 character minimum for passwords.

Re:libpam-cracklib

[StarkRG]

And while you're at it, no repeated characters either. Time to break out the chinese input program!

Re:libpam-cracklib

[ArbitraryConstant]

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.

Re:libpam-cracklib

[teslar]

You're laughing, but in practice I have too often seen restrictions on the maximal security of passwords.
Take for instance my online banking system (which in its defense has other security measures alongside the password, but still):

• no more than 10 characters please
  
• upper/or lowercase does not matter, lowercase will automatically be converted to uppercase
  
• alphanumeric characters only

Seriously, what's the point of this?? Why am I forced to use weak passwords just because some developper somewhere can't figure out how to allow a " or a \ in a string?

password requirements

[PetriBORG]

Hopefully then they will also implement a good set of password rules and enforce them to protect themselves from future problems. Where I work they require 3 out of the 4 rules to be met such as mixed case, numbers and special characters... of course they also make us change our password every 30 days so i've discovered that people have taken to doing things like Asdf1234 and then when the password requires changing changing it to Asdf2345... Doh.

Re:password requirements

[Bostik]

Hopefully then they will also implement a good set of password rules and enforce them...

I have a suggestion. Dump the password based access altogether. These are Debian developers, who by their position already NEED to both know and understand how to use GPG for signing their uploads. The concept of public-key access control/validation is their bread and butter.

Allow only public-key SSH access to Debian machines. Period.

That way, to compromise Debian server(s), any potential attacker would need to daisy-chain their targets. Break a developer's home or work box first, get their keys and their passphrases. Only then can they proceed to bigger targets.

I wonder...

[MSFanBoi2]

Why when this happens on a Windows server is "OMG! Windows is insecure! M$ is evil!!!!"

But with this its "Oh just set more difficult passwords"...

Re:I wonder...

[The Bungi]

Did you miss the part where a local Linux kernel exploit was used in the attack?

Re:I wonder...

[Anonymous Coward]

Did you fail to understand what a remote exploit is?

Here, let's try an analogy. In this case someone left the door to the building unlocked. A burglar got in. He then methodically cracked the safe, and took the money from within.
  Following this, "MSFanBoi" posts to slashdot making a false equivalency between that and the Win building where the locks were defective and the money was taken from where it was sitting on the floor. (The windows exploits being criticised are remote, the linux exploit was local-only. In the latter, you have to actually break in before they are useful.)
  Do you still fail to see the difference?

Re:I wonder...

[TrappedByMyself]

Why when this happens on a Windows server is "OMG! Windows is insecure! M$ is evil!!!!"

Don't forget that people would be making fun of the incompetent MCSE admin for not enforcing a complex password policy

If only they'd...

[a_greer2005]

been running with the stability and security of Windows Server, they wouldnt have had this happen. They would have kept their service up and agile for the furtherance of the enterprising endvors of hacking...er...uhhh...computer science research.

Bill G.

ssh2 keys?

[saleenS281]

Why don't they just have the developers use ssh2 keys? I didn't know anyone actually used passwords on secure systems for authentication...

Re:ssh2 keys?

[Gregg Alan]

Why don't they just have the developers use ssh2 keys? I didn't know anyone actually used passwords on secure systems for authentication...

Agreed. Don't we all know this already? I don't have anywhere near the number of users that Debian does, but it's keys all the way.

On the other hand, if they used a weak password for something as serious as Debian developer access who's to say that their workstation/personal network/whatever wouldn't be compromised and leak the encrypted key and then the key (assuming they have a weak passphrase).

I smell a sleeper.

Re:ssh2 keys?

[Just Some Guy]

This is a good idea, although distribution is a problem. The key could be sent in an encrypted mail to the user, with the password set to something specified in another encrypted mail.

Ummm, no. Debian takes the whole "web of trust" thing seriously. That means that developer joecoder@example.com generates his own SSH public key and sends it in a signed email to the development server's administrator. That person verifies the email signature and puts the key in ~joecoder/.ssh/authorized_keys. Nothing more need be done.

Re:ssh2 keys?

[mibus]

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.

Re:ssh2 keys?

[AirLace]

Sure, but that's why every Debian developer has to have a GPG key. It's a requirement of the project, and GPG keys are proof of identity and revocable, and what's more, they can be used to sign SSH keys. That's how freedesktop.org works, and that's how Debian would have been working today if its hierarchy of command hadn't crumbled years ago and someone were actually in the position to mandate that logins should be done by PKI.

That said, pretty much everything else in the Debian project appears to work fine without centralised control -- it's just the little things like this that slip.

Re:So?

[PetriBORG]

I guess I should be more specific. My point was that people were puting strings of letters and or numbers in sequence as their password because they were forced to change them so frequently. I would argue that any string which is sequential is less secure then a randomized number. Like putting 1234 as your ATM pin... it leads to easy shoulder serfing.

Thus people would pick their first name, Peter123 if I was to use my own name as an example. I'm comparing this to passwords that I had to use at Sandia National Labs which were randomized letters and number strings generated by computer, the user was presented with a screen of 30 passwords and you were allowed to pick any of the 30, or to generate a screen of 30 more passwords... The people would pick things that made sense to them but were completely randomized and were never a dictionary word or even a common short hand for the words etc.

B...b...b...

[htnprm]

...but it's Linux!

Secure Passwords lead to Insecure Passwords

[cloricus]

I have noticed what you talk about though I've seen it go to further extremes. While at work (we run a mainly Windows network with a few hundred users) I've done further education (out side of Uni) at Australian TAFEs (basically vocational collages) in Queensland - the TAFE I went to runs a pure Windows network with around twenty thousand plus users over several sites...Any one who has been to one of these TAFEs understands how much of a raping they have taken from Microsoft, and I say raping because they run the 'perfect Windows network' following all of Microsoft guidelines etc which mean some machines take over fifteen minutes to log in and are laggy as all hell once they are in.

Anyway onto the topic. They also follow the recommended guidelines for passwords which includes at least one capital, two numbers, over six chars, and cannot be any of your previous passwords (with I believe a 80% match so you can't just add a 1 or a 2 to it) and these roll every thirty days. Now as a geek I have my own unique password system where no two are the same, they are long, and they have numbers, and at least one capital - unfortunately there is only five or six possible combinations that meet the password system for each item meaning after five months going to this TAFE (I was there a year part time) I ran out of passwords. This put me on the tred mill that every one else had been on for a few months (they did a fresh roll over to XP from 98 at the start of last year) of forgetting the password (that I made up to get into the system after my old one expired) or where I wrote it down (yes, every one wrote down their passwords in blatant places so they could find them again, which to me makes passwords null anyway) and then starting to use generic passwords that every one else was using that month for example t4f3IsShit or fUkp455words and the like. As you can probably see this just ends up a mockery of the idea.

So basically the point I'm trying to make is you have to be careful with what you mean by a 'good set of password rules' as if you go overboard even to the slightest extent (as I've seen happen time and time again) passwords just become a joke and you may as well not have them.

Personally I've found that if you teach people/users what a secure password is, teach them not to tell it to any one, get them to use firefox to avoid keyloggers, and then enforce a six to twelve month roll over no problems ever come up. That's my happy medium and 2cents anyway. :)

Re:Passwords

[Anonymous Coward]

By running cracking tools against them, of course.

good idea

[smash]

I mean, it's one thing to use an insecure password on your personal machine - but using an insecure password on a common development machine for a fairly high profile project is just irresponsible.

Locking them out is totally fair, and imho it's the responsible thing to do.

STRONG passwords should be enforced (hell, mandatory keyed logins would be better) on machines like this (which are fairly attractive targets for abuse)...

Fresh Change

[1trickymicky]

For once it's not a compromised windows based system we're waiting for a bug fix on...

*gasp*!

[grasshoppa]

Goodness, no! This might push them behind schedule!

Re:Passwords

[sholden]

There's no way you could be dumb enough to actually think that.

Re:So?

[TCM]

How the hell could this be modded insightful? The whole point of changing passwords is so that the compromise of one password doesn't lead to unlimited access or the compromise of future passwords.

If a password is so secure that it can't be guessed, then why change it? If it's so weak that it gets guessed monthly, changing just one digit doesn't do shit.

And if the system gets compromised, you reinstall and choose a totally different password.

Seriously, this must be the most stupid advice I've seen and it's currently +2, Insightful. Scary.

Re:WTF?!!!

[linvir]

Old password:
> ******
New password:
> *****
Retype new password:
> *****

WARNING
This is a really stupid password, the kind that would put this entire computer at risk.
Are you sure you want to continue?
[ Y / n ]
> Y

BASTARD
Okay then, fuck you. Your account has been completely cleared out, to help you understand the importance of choosing a secure password.

Now, let's try again, shall we?
Old password:
>

Re:Passwords

[ozbird]

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.)

Keys need protection as well

[SIGBUS]

However, said keys better be passphrase- (NOT password-) protected! After all, if, let's say, $DEVELOPER's laptop gets stolen and it has a non-passphrase-protected ssh key, then going to the effort of using keys for authentication will be for naught.

FWIW, I recently ditched Debian for a completely unrelated reason (see also, CVE-2006-1173).

Re:Keys need protection as well

[Bishop]

CVE-2006-1173 is vulnerability in Sendmail. Debian uses Exim by default. Why would CVE-2006-1173 cause you to ditch debian?

Re:Passwords

[Lehk228]

dictionary attack with custom dictionaries (star wars, star trek, LoTR, DnD, Shadowrun, david weber, william gibson)

that will result in a devastating number of password cracks.

Cracking "weak" passwords is trivially easy

[xactoguy]

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.

Re:Weak Passwords ?? If they know that ...well

[Anonymous Coward]

Believe me, the Debian project does not store passwords in the clear.

As administrators they have access to the shadow file that contains hashed versions of all the passwords. What they did was run a cracking utility against the shadow file to pick out weak passwords. Usually these cracking utilities use brute force dictionary attacks to try and randomly guess the password. If the utility was able to guess a password quickly, that password was definitely not secure. It's as simple as that.

I encourage you to read more about the topic, it's a fascinating one. Wikipedia has an interesting article at http://en.wikipedia.org/wiki/Password_cracking/.

Re:Weak Passwords ?? If they know that ...well

[Acc7]

Reply posters,

Interesting comments (except that one anon creature).. Yes, when one has access to the hashed password files, the test is a lot easier than a wholesale crack.

And the net is not exactly a place to send anything that one doesn't want snniffed, is it.

But by leaving us to guess why & how, Debian did leave the door open to speculation on just what they did that opened this vulnerability and what they did to "determine" there were weak passwords. And I was not knocking the Debian code, just the management errors that led to this particular problem.

And the question about the kernekl version is also a valid curiosity, isn't it. btw do they actually know that this was a hack from outside, entirely outside?

As to credibility, would rather see a good open discussion than waste time with name calling any day.

Accounts with bad passwords locked, not all

[dondelelcaro]

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.

Re:Oh the irony!

[Architect_sasyr]

Oh yeah? Someone has been playing on their network for months, and we know of it only because one of their employees blabbed about it.

As no doubt others will make the same case, the difference here is not that Debian got pwned or the Microscum (personal bias aside ;) are any worse/better. The deal is that Microsoft stands to lose a hell of a lot more by saying they have been owned, especially with the new "secure" vista coming out.

Anyone know of the latest citibank cracks? Funny, no banks will tell us that they have been cracked, yet they are not ripped on as much...

Your new Debian password.

[Savage-Rabbit]

Dear Mr finiteSet,
To punish you for using such a weak password to your Debian developer account we have changed your password to the following:
!_@m_@n_!ns3ns!t!v3_cl0d_wh0_us3s_w3@k_p@ssw0rds_b ut_!_pr0m!s3_n0t_t0_d0_!t_@g@!n_s0_l0ng_@s_!_l!v3

Enjoy
The Debian team

Re:Your new Debian password.

[jackbird]

Since they are rightfully in posession of the passwords file and usernames on the system, I imagine they ran a dictionary attack against all the user accounts.

Chip and Pin

[giafly]

I use my credit card Chip and Pin number as my password. If you do the same, you'll be completely secure, because it's the one thing that cannot be forged. Don't just take my word for it, check out these quality endorsements:

• "Your PIN cannot be forged" - Halifax Bank
• "the PIN can't be forged" - Alliance & Leicester
• "the PIN, unlike a signature, cannot be forged" - extra direct Banking

Overreacting a bit?

[rai4shu2]

"Due to the short window between exploiting the kernel and Debian admins noticing, the attacker hadn't time/inclination to cause much damage," wrote Schulze.

"The only obviously compromised binary was /bin/ping. The compromised account did not have access to any of the restricted Debian hosts. Hence, neither the regular nor the security archive had a chance to be compromised."

It seems like nothing much really happened. I mean, if this is all a hacker is capable of even with root access to a major Debian server, then what's all the fuss about?

howto: strong passwords

[dune73]

If you are in need of a strong password, use the following recipe:

Think of a sentence with 6-10 words with a number in it.
- The number can be inside one of the words.
- If you manage to have multiple Capital words in the sentence, your password gets stronger.

Then take the first letter and write the numbers as digit, include the point,
question mark, exclamation point at the end and you got a strong password.

Today i ate two buns for breakfast! -> Tia2bfb!
I have seen six dups on Slashdot this week. -> Ihs6doStw.
Can you memorize all four new passwords? -> Cyma4np?
And today: A new password for my debian account! -> At:1npfmda!

Works fine for me and is fairly easy to memorize.

Re:howto: strong passwords

[Just Some Guy]

If you are in need of a strong password, use the following recipe:

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.

Re:howto: strong passwords

[kchrist]

I have seen six dups on Slashdot this week.

That's far too easy to guess.

Again?

[wobblie]

As a long time Debian user I am not so surprised by this - it is just the reality when you operate a system with thousands of user & shell accounts all over the world. It isn't that big of a deal if the debian admins respond correctly, which they always do, but it looks bad.

The issue that gets me is this is the second time the Debian system has been compromised, and in the exact same way - a local kernel exploit from a compromised DD account. As good as the Debian security team is, they are frankly terrible with the kernel. The Linux kernel has continual local security exploits (I am not in denial about that); these don't matter so much for most deployments but for the Debian system they are absolutely critical because of all the shell accounts. The Debian kernel team really needs to work out something better (though I know the issue is more complicated than that); this is the one thing Red Hat does very well. I cannot for the life of me understand why debian servers kernels are not upgraded continually. The downtime is immaterial compared to something like this.

Re:Again?

[noahm]

As good as the Debian security team is, they are frankly terrible with the kernel.

The servers compromised, in both cases, were not running kernels supported by the debian security team. The Debian sysadmin people typically roll their own kernels for use on Debian.org machines. In fact, had the default stable kernel been used, the machine would not have been vulnerable to this exploit. See http://lists.debian.org/debian-news/debian-news-20 06/msg00030.html for more info. (In short, 2.6.8 is not vulnerable.) The compomised server was running a custom 2.6.16.18 kernel, and was thus vulnerable. It has since been upgraded to a custom 2.6.17.4 kernel. If you're going to knock anybody in this case, knock the Debian sysadmins for not keeping up with security on their own machines, or for having policies in place that allow weak passwords to lead to any kind of access. But don't knock the Debian security team.

The Debian security team has fixed 98 kernel security bugs since sarge was first released. Refer to changelogs for the kernel-source-2.6.8 versions 4sarge1, 4sarge2, and 4sarge3 for details if you need them. What more do you want?

noah

how did he get root?

[Intangion]

how did he get root from shelling in as a user?
i was under the impression that exploits that are patched as soon as they are discovered
id hope a debian developer machine wouldn't allow any kind of known exploit

Passwords? Are you nuts ?

[m.dillon]

There shouldn't be any passworded accounts on a developer machine at all. It should be SSH access via public key only, period end of story. I stopped using remotely accepted passwords over a decade ago. Passwords are only accepted on the console.

Come on, folks. This is UNIX-101. Don't be stupid.

-Matt