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

[ArbitraryConstant]

Am I the only one that simply got used to memorizing random 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

[El_Muerte_TDS]

That's why my password is: 12345
Nobody will guess that, it's so simple. That's the kind of password an idiot would have on his luggage.

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

[axllent]

Liar ;-)

Re:Ah. balance

[kcbanner]

Recieving emails asking for your password hmmm suspicious. Dont come up with a shiny new password to feed the Phish with.

Re:Ah. balance

[ThePhilips]

... securely encrypted file.

And what would happen if you forget the password for the file with passwords?

Sorry my naivity. I keep my passwords (and serial keys) in plain text file. The solution works 100% with all OSs I work (and used to work) - Linux/Wind0ze/MacOSX. The only "security" feature - file is kept on external hard drive. Not intentionally, but after another totaled hard drive I bought external disk for backup. The file with passwords was one of few recovered from failed hard drive. Since then it's there.

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

[albalbo]

I agree about key authentication, in general. But - it doesn't play well with, eg., sudo.

If you have users who are setup to use sudo (for example, to update a website area, or something), they cannot use their keys to authenticate themselves to sudo. At least, if there is a way, I'm blissfully ignorant and would love to hear about it ;)

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

[Fred_A]

I just use the same password I use on my luggage. That way it's easyer to remember.

Re:Ah. balance

[biftek]

Having implemented rudimentary PAM support for a SSH server, I'd have to say that I agree that PAM is somewhat horrible. It appears that it works great for it's original intended purpose of printf() at a login prompt, but not for much else without jumping through hoops.

Re:Ah. balance

[Fred_A]

I've been using Keyring for Palm for years.
It triple-DES encrypts the data stored into it and is open source. It can also generate passwords. Basically it just encrypts little memos, which is ok to store access info (login / pass) or sensitive data.

In case of loss of the unit, you can read the file with a palm emulator easily enough provided you remember the master password.

There are commercial equivalents for those who want a more fancy interface. I don't know what's available for other handhelds...

Re:Ah. balance

[ObsessiveMathsFreak]

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

I used to get that feeling, then I got apg. It has the option of either generating totally random passwords, or by defualt, generating "pronouncable" passwords. It even gives you the phonetic pronouciation. Here's a sample output.

[omf@mathsbox ~]$ apg -t
NialusekCy (Nial-us-ek-Cy)
fevuvUft (fev-uv-Uft)
yugyekvod (yug-yek-vod)
yalcutyed (yal-cut-yed)
diOwGhorc (di-Ow-Ghorc)
TremecOk1 (Trem-ec-Ok-ONE)


You can do this all day. Password generation is simply not difficult anymore.

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

[dnoyeb]

I thought that was silly for years while using Redhat. When I switched to Mandriva I was happy to see the default was no.

I also disable password login and only allow keyfiles. Which is more secure than the password because a password can be hacked from anywhere but a keyfile needs to be obtained locally. (wouldnt help in this case).

Also I typs 'su' when I need root access. The dev account being hacked is not so big a deal as the local root exploit.

Re:Ah. balance

[getwhipped]

I like to create a sentence that works as an acronym, where I could possibly insert a number. Such as: "Give a man a fish, and he'll eat for a day." The password would be: gamafahe4ad This makes the password hard to guess, yet easy to recall.

Re:Ah. balance

[idontgno]

then I got apg

UConn has an online version, for those who don't feel like installing and running a local program. I was crazy enough to configure it to build me an SSID (useless for security, but at least it doesn't scream "N00B" like leaving the default value) and WPA PSK.

Re:Ah. balance

[Reverend528]

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

The best solution I have found is to use chemical equations. If you can remember the reactants, then you can figure out the products. It's the easiest way I've found to remember passwords with 20+ characters.

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]

It wouldn't square the time, it'd 2^8 it.

Re:Ah. balance

[BecomingLumberg]

Indeed. Please forgive the mistake on account of the 7am-ish timestamp.

Re:Ah. balance

[YU Nicks NE Way]

Just to echo and highlight what arivanov said, it sounds to me like this attack was a two-stage attack, in which a developer's machine was compromised and used as a jumping-off point for an attack on the Debian server. The strength of the developer's password was irrelevant, in that case; a root kit on the developer box would have exposed any password, however strong, or any SSL private key stored on the box.

(And, yes, there are root kits for Linux, Mac OS X, and FreeBSD, as well as for Windows. So the fact that a Debian dev is almost certainly running Debian provides no real protection.)

Re:Ah. balance

[lbrandy]

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

Does it make me crazy if I read that and tried to verbally make a squirrel noise? My cube-neighbor thinks it does.

Re:Ah. balance

[Antique Geekmeister]

This works until your machine gets rootkitted and the attacker notices a file called "passwds.txt". It's particularly fun for people who store their passwords and SSH private keys on USB keychains "for security", then leave them behind while traveling.

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

[BecomingLumberg]

Apology accepted. Punishment shall be an immediate trip to the local coffee shop. All obstacles should be scowled at.

I still accept blame for my pathetic spelling though.

Re:Ah. balance

[marcello_dl]

Nope :) Another common technique is: Use The Initials Of A Phrase That's Easy To Remember (utioptitr) as base for your pass.

Re:Ah. balance

[fimbulvetr]

Let me get this straight. You go to a website to have a password generated, leaving them with:

(a) An IP address of yours
(b) Some type of password of yours

???

Re:Ah. balance

[smellsofbikes]

Dude, they gave the-artist-formerly-known-as-prince access to debian developer stuff? That's *great*! Finally an OS with a good soundtrack!

Re:Ah. balance

[monkeydo]

We apparantly have different definitions of "pronouncable".

Re:Ah. balance

[plague3106]

Not true. Any intelligent public / private key authentication will keep the private key under a password, so that if its stolen, it can't be used.

Re:Ah. balance

[rhaig]

fecking whiney users. create a complex password that isn't hard to remember. use keyboard patterns, or just memorize.

examples of keyboard patterns that are hard to guess, easy to remember
a1s2D#F$
zqxwCEVR
/.;lpo)(
you get the idea.

Re:Ah. balance

[MorderVonAllem]

MOD Parent up! If I had any, you'd get them. Great reference.

Re:Ah. balance

[The Conductor]

On sytems that don't put boneheaded limits on password length, you can strengthen the password at, in terms of human memory, no cost by simply typing the whole thing, and if you don't bother with caps or punctuation, it is not much longer or error prone to type. In your example: usetheinitialsofaprhasethatseasytoremember. Not as much entropy of the same number of random characters, but more than utioaptetr, which could also be underlinetheinitialsofaphrasethatseasytorealize.

Re:Ah. balance

[intangible]

Unfortunately, if you are the owner of the private key, you can remove the password, so Debian wouldn't be able to enforce strong passwords on the key.

Re:Ah. balance

[Lennie]

You are not afraid the password & IP-address was logged at that webserver or an in between ?

Re:Ah. balance

[compass46]

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

Integrating PAM and SSH is the job of the SSH portable developers not the OpenBSD developers. PAM does not exist on OpenBSD and will not. Complain to the developers who work on the SSH portable branch instead.

Re:Ah. balance

[plague3106]

This is true; I was mearly commenting that yes, you still need a password.

Re:Ah. balance

[Aeamarth]

Quick! Change the password of my luggage!

Re:Ah. balance

[DaGoatSpanka]

That's the funniest thing I've heard all day! Keep up the good work, sir!

Re:Ah. balance

[Ant P.]

Actually that'd be a great idea, if not for the problem that those sort of idiots could then guess your password on the first try.

Re:Ah. balance

[shish]

Moderation of funny and someone calls you a liar o_O? Well, maybe you are joking, but I don't see randomly generated 16+ character passwords as unrealistic -- I have about 20 randomly generated 8 character passwords I use on a daily basis, and a further 50 stored in an encrypted passwords.txt file (when the master password is over 100 characters, you quickly come to find memorising 8 character sequences much more convenient -- I'm so used to the system that I rarely have to look up the password more than once or twice before I've remembered it :)

Maybe I just have good memory for such things though, I still remember a psychology class from two years ago where we split into two groups, mine had 30 seconds to memorise "MPIBMITVAAFBIRAF", another had 30 seconds to memorise "MP IBM ITV AA FBI RAF" (All common acronyms in the UK). Even though I didn't spot that they were common acronyms and ended up memorising it as a solid block, I still had the best recall of either group XD I also memorised "NYM PYD CNL RKT FCT" in 10 seconds as being the racket factory by the canal of nym pyd, a fictional Welsh town I invented just so that I could remember it...

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

Re:Ah. balance

[killerkalamari]

I'm curious, what is the increased security benefit of "LoginGraceTime 2m"?

Re:Ah. balance

[Squirrelgirl]

You could always go there from another computer.. ;)

Re:Ah. balance

[idontgno]

(a) An IP address of yours
(b) Some type of password of yours

Well, actually, in my case, (A) an IP address at the local uni library, and (B) a list of 150 possible passwords. But good point. It could, indeed, be used carelessly. But not everyone feels like installing random software from random websites to "securely" build locally-generated passwords. ("Securely" if the software isn't a trojan, that is.)

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

Re:back to normal

[cow-orker]

Bah, it's just the usual slashdot misinterpretation. Priviledge escalation was used to break in, so the cracker had local access before. The admins looked for weak passwords that could have been guessed and locked those users out. They can get back in if they use sensible passwords.

Nothing to see here, please move on.

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

[vinohradska]

It's nice to know that the Ubuntu update I ran this morning for passwd 1:4.0.13-7ubuntu3.2, was based on a real security notice: SEE HERE, and not some hacker installing a backdoor.

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.

Re:kernel exploited...

[Zoxed]

> I guess this means that there are a lot of ubuntu users out there who are vunerable right now... how long for the patch?

According to here Ubuntu is already patch, and the fix is 6 months old.

Re:kernel exploited...

[Mind Booster Noori]

More importantly, it means that gluck isn't using Debian stable, which is obviously a shameless wrong decision.

Re:kernel exploited...

[ajs318]

Debian don't consider the kernel part of the distribution. It's still Sarge, whether it's running on 2.2 (yes, you can), 2.4 or 2.6.

Re:kernel exploited...

[Mind Booster Noori]

Debian don't consider the kernel part of the distribution. It's still Sarge, whether it's running on 2.2 (yes, you can), 2.4 or 2.6.

I'm sorry, but that's completely false. The kernel is part of the distro, and the kernel-image for sarge is 2.6.8 (not vulnerable). And yes, I know there are also packages for 2.2 and 2.4 on Debian.

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

[FooAtWFU]

It's called public-key authentication. Well, 1024-bit keys ~= 128 characters... but that's not quite the same thing really.

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

[danme]

Yeah, and let's require that the password is changed every week too!

(Oh, and don't forget to adjust the screensaver to lock if not using the machine for 10 mins... Oh, how I hate admins who require that in windows networks).

Re:libpam-cracklib

[matth]

Why? That prevents un-authorized use of the company machine.

Re:libpam-cracklib

[danme]

Yepp, but if you discuss something with the person next to you, you dont want to reauthorize again. If this happens several times per day it is very frustrating. (Additionally, all people around you should already have their own local accounts. And if you really want to (mis)use another persons account, you just have to wait until the person temporary leaves their computer). I think the security increase given by such a restriction is *very* small (30+ mins or so is okay though to make sure people have logged out when leaving for the day)).

Re:libpam-cracklib

[Joebert]

Time to enforce a 200 character minimum for passwords.

I hope you're kidding, I can't even formulate a 200 character comment.
Oh well, my trusty password manager only makes me use 6 characters.

Re:libpam-cracklib

[fbjon]

Why the difference in search space?

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?

Re:libpam-cracklib

[vadim_t]

IIRC, the keys can only be prime numbers.

Re:libpam-cracklib

[lav-chan]

Why am I forced to use weak passwords

Because some developper somewhere can't figure out how to allow a " or a \ in a string.

Re:libpam-cracklib

[Dantu]

Seriously, what's the point of this??

Probably still usin EBCDIC to avoid problems with thier punch cards caused by the evil ASCII (and just forget UTF-x).

Re:libpam-cracklib

[InfiniteWisdom]

I'm not saying they should't allow longer or non-alphanumeric passwords,but you're hardly being forced to use a "weak" password... there are 3,656,158,440,062,976 ten character long case-insensitive alphanumeric passwords (36^10). It would take an adversary trying out a million combinations a second over 115 years to explore the whole state space.

Re:libpam-cracklib

[Intron]

Because they will also lock your account when more than 3 (or 4 or 5) attempts fail in a row. You don't need a super-strong password in that case, since you have no way to crack it offline.

Re:libpam-cracklib

[MobyDisk]

I don't think you will find a security book/article that says that account lockouts mean that there is no need for strong passwords.

Re:libpam-cracklib

[djdavetrouble]

my password is Jabberwocky in its entiretly with underscores for spaces and numbers replacing all of the vowels, 1337 style, rot-13'd
and backwards. Can't be TOO safe...

And on a side note, isn't the microsoft VisualStudio2005 banner freaking annoying ? Its the one that expands to a huge box when you mouse over it.

Re:libpam-cracklib

[PetoskeyGuy]

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?

The most common reason I've seen developers do this is because they don't understand database collation. I have seen sites store passwords as plaintext in the database, then so a simple "select * from accounts where account = 'account' and password = 'pass'". Most databases are not case sensitive by default so they end up allowing any combination of upper and lowercase numbers.

Random somewhat out of context tip, but for MySQL your web developers can use...

    insert into accounts( account, password ) values ( 'acc1', 'Test' ), ('acc2', 'TeSt'), ('acc3', 'TEST'), ('acc4', 'test');

    select * from accounts where password = 'test' collate latin1_swedish_ci;
      -> default, returns all rows above
    select * from accounts where password = 'test' collate latin1_bin;
      -> case sensitive, returns only acc4
se

Re:libpam-cracklib

[slackmaster2000]

I think the bigger problem is storing passwords in plaintext to begin with. I can think of no reason to do this in an online banking system. There are a dozen ways to hash a password without any real work on the part of the developer (in its simplest form, a slight modification to the query is all that's required). Forgotten passwords should always result in a reset.

I have a hard time believing that a bank would have such a silly system in place though. Perhaps they restrict passwords to reduce support calls, or maybe they view writing down strong passwords to remember them as a larger problem than weak passwords. Neither excuse seems reasonable. Isn't banking software regulated in any way?

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

[darkmeridian]

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

Even so, the use of caps and symbols open the universe of possible characters in a password so as to make brute forcing harder and dictionary attacks neigh impossible. Who the heck keeps Asdf2345 in their dictionary as opposed to asdf1234?

Re:password requirements

[smash]

Or even better, they'll realise that the whole concept of passwords is broken and they'll start using private/public keys like everyone else with an internet-connected machine who cares about security.

Re:password requirements

[staeiou]

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.

I am really curious how you know exactly what your users are setting their passwords to. When properly hashed, Asdf1234 should look completely different from Asdf2345. Either your company is having users submit new passwords over plaintext to admins who manually change them, your users share their passwords when asked, or your system uses a very weak hash that you can break. All of these scenarios are dangerous from a security standpoint. You shouldn't ever be able to find out a user's password, even if you have root access.

Re:password requirements

[dorath]

The longer the password, the longer it takes to force.

"Ih8c@ts" is seven characters long, contains uppercase, lowercase, a number, and @. But is it really more secure than "ireallyhatecats"? In a system where the same characters as the former are acceptable, the length of the second one means it will require more resources than the former.

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.

Re:password requirements

[ars]

That's why you should not require people to change their password.

Yes I know everyone tells you it's important - they are wrong. Unless you are in the millitary requiring poeple to frquently change their passwords leads to WEAKER passwords.

I've seen it over and over, they'll pick easy to remember (and thus crack) passwords, write them down, use the same password everywhere, all kinds of bad things.

Make them set ONE good password, and leave it like that.

Re:password requirements

[csirac]

If you're methodically iterating through every combination of every printable character in the ASCII table, sure.

But my understanding is that crackers take advantage of simplisitc, dictionary-based passwords by first trying out obvious dictionary words and combinations of dictionary words first, which is much much faster even though this will result in longer passwords (as there are fewer combinations to try).

Re:password requirements

[ClosedSource]

But isn't this really about the relationship between what a cracker assumes passwords will be like and what they actually are. If they assumed people were using "strong" passwords wouldn't "weak" passwords actually be more difficult to crack (assuming equal length)?

Re:password requirements

[stevey]

I am really curious how you know exactly what your users are setting their passwords to.

Maybe they were just examples..?

But there are programs designed to detect weak passwords, which could have been what was used. Essentially they try to bruteforce passwords, and if they find one it was weak!

Re:password requirements

[cortana]

Why can't OpenSSH use PGP keys for challenge/response authentication? Then DDs would only have one private key to keep track of.

I wonder how much this intrusion has cost the project, and how that value compares to the cost of setting up and distributing to developers security tokens or smart cards.

Of course, in this case the developer's machine was cracked (I wonder how?) and so none of these precautions would have prevented the breech.

Re:password requirements

[Cutting_Crew]

here where i work you have to used mixed letters/numbers and lowercase/uppercase and is a minumum of 8 characters. password reset is every 90 days but you cannot reuse your LAST 20 passwords. imagine that.. better get out that thinking cap and come up with something that i can remember. this is running windows xp pro too..

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

[heinousjay]

Zealotry is partially defined by the ability to hold beliefs that are in direct contradiction.

There is no joy in pointing this out.

Re:I wonder...

[The Bungi]

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

Re:I wonder...

[HotBlackDessiato]

I think the comments + artical above clearly indicated a kernel vulnerabilty was involved. Let's at least agree on a correct starting point before jumping onto the linux vs. windows hay ride.

Re:I wonder...

[Cheapy]

Buddie, you're name isn't helping your case one bit.

But the sad thing is...he's right.

Re:I wonder...

[Anonymous Coward]

There is a huge difference between a local exploit and a remote exploit. Most Windows problems involve remote exploits. This is why Windows is considered so insecure. If you have a personal (single user) machine and don't run servers that allow remote logins then local exploits are of little/no concern to you. Not so for remote exploits. Understand now?

Re:I wonder...

[The Bungi]

Either way

ROFL. No wonder this thread started making a point about the zealots coming out of the woodwork.

Re:I wonder...

[jasonwc]

"Oh, and no exploit on any non-Windows system has ever allowed an attacker to get administrator access by looking in a fracking picture like one MS exploit did."

...Someone has been watching too much Battlestar Galactica.

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

[smash]

Actually, no he's not.

This wasn't a remote exploit.

If you give away logins on any machine, people will likely be able to use some local exploit to own the box.

Most of the Windows security problems we bitch about involve REMOTE exploits with no user account necessary.

Re:I wonder...

[JebusIsLord]

There is no such thing! Besides I love "frack". I use it all the time at work. I can tell it upsets management, but they are powerless to stop me! Whahahahaha!

Re:I wonder...

[Aadain2001]

"Did you miss the part where a local Linux kernel exploit was used in the attack?" True, it was part of the exploit, but first the attacker(s) had to get onto the system using a developer's account. Now I don't pretend to know what kind of rights the developer accounts have, but they would definately have more power than a "guest" account or the account used by apache if that had been hacked. This means that if the account hadn't been hacked, then the server wouldn't have been hacked (exploit requires user access to the server). The kernel exploit is bad, but at least they are upfront about it and don't try to hide it behind PR/marketing speak or not tell anyone about it.

Re:I wonder...

[1u3hr]

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

By itself, it didn't give access. It was used to elevate privileges AFTER the password was compromised.

Re:I wonder...

[xilmaril]

Because on slashdot, just like absolutely everywhere else, most people are illogical.

Oh, wait. you didn't want the obvious truth, did you?

Um, it's because lunix is teh r0xx0r, yeah. that must be it.

Re:I wonder...

[toadlife]

"Oh, and no exploit on any non-Windows system has ever allowed an attacker to get administrator access by looking in a fracking picture like one MS exploit did."

The WMF vulnerability did not escalate priviledges. It ran code with the rights of the logged on user. As for non-Windows systems, there have been plenty of vulnerabilities that can be trigggered by looking at a picture, like this, and this, and this and this. I'm sure I could have found more, but I didn't feel like going past page two of my Google search.

"Either way, I mostly use FreeBSD now anyways."

As long time FreeBSD user, I must say I'm sorry to hear that.

Re:I wonder...

[Anonymous MadCoe]

Quite funny to see people see your comment as a Linux vs. Windows comment....
While you (if I read it correctly ;-) ) point out that problems with Windows security are treated very differently on /. from problems with OSS security...

That is a bit of a shame I think. If there would be a good balance, the comments here would actually bear some weight, not it just reads like some zealotry.

This zealotry is easilly counterred by marketing people, a balanced view that is obviously credible is a lot harder to counter...

Ah well...

Re:I wonder...

[drsmithy]

Most Windows exploits are OS exploits.

Most "Windows" exploits are Windows *user* exploits.

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

Re:I wonder...

[Tony Hoyle]

BSG didn't invent that - I can remember it from my school days.. there was an old BBC Micro program where the character would should "FRAK!" when it died.. it was hillarious to me as a child :p

Re:I wonder...

[The Bungi]

Did you fail to understand what a remote exploit is?

Apparently you failed to completely grasp what I said. But regardless, it's hilarious that someone actually modded you up. In a thread about zealots. Thanks so much for the chuckles.

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?

[growse]

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. Once you've got the problem about giving the user a key and telling them the passphrase, you've actually got something that's pretty damn secure.

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?

[miro f]

well remember what they're distributing is a public key, so it doesn't need to be very secure (so long as it's not hijacked and changed along the way)

Re:ssh2 keys?

[Geekenstein]

I don't think you understand the subject you're trying to speak to here...SSH keys are a public key system. The user generates his own key and sends the public portion to the server. The private key is never transmitted anywhere.

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?

[Frosty Piss]

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

Sorry for being ignorant (honest!), but as a non-developer type, I'm unclear the concept. How does ssh2 keys do away with passwords?

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?

[smash]

First up, i agree with the GP post.

How it works:

You are given a "private key" (optionally further secured by a password), by the administrator of the system that corresponds to the public key on the server.

Instead of your password being sent to the server, authentication is performed by using your private key to send encrypted information to the ssh server, which is then decrypted/authenticated with the public key. If the keys don't match (as a "keyed" pair, they're not identical), you don't get in.

Compared to passwords (which are typically 8 characters or less), the public/private key pairs can be 1024 bits or larger, and randomly generated (as opposed to passwords which are very NOT random).

This makes the whole setup more secure.

The password (optional) on your private key simply stops (or rather, slows down) someone who has stolen/obtained access to your private key from being able to use it without supplying a password.

If the private key is lost/stolen, you simply revoke it by generating a new public/private key pair, and reissue the private key to the end user via a "secure" channel (physical media, one time passworded connection or whatever).

That's the laymans rundown... technically it might happen a little different to that, but that's the general idea..

Re:ssh2 keys?

[smash]

Or, see the post below mine, which doesn't do it ass-about, and relies on the end user to generate the key-pair and send the public key to the system admin of the device you want to access.

The public key can be stolen/seen - it can't be used for authentication, so you avoid the requirement for a secure channel to transmit your private key back to you.

I'm just used to dealing with users who don't know how to generate their own private keys, so i do it for them... and have to give them their private key myself...

Re:ssh2 keys?

[dsouth]

SSH keys are not a cure-all. In fact, they can be worse than passwords.

Yes worse. Ssh keys are not certificates -- they don't expire and are not revokable. So, if someone compromises your private key, they get access to every host that has your pub key until you visit each host and delete the offending key. Add to this the fact that users can (and often do) create ssh keypairs without putting a password on the private key and the fact that there's no way for an admin to detect and inforce password protection of private keys on off-site machines, and you see the problem.Many sites configure sshd to deny ssh-key access from off-site for just these reasons.

If you're using ssh keys, put a strong password on the private key (man ssh-agent).

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:ssh2 keys?

[Cutting_Crew]

better yet why dont they use a version of Kerberos ?? seems to be this is more secure.. as it requires a normal password but also you have a pin number that displays a separate password to authenticate the user on the client side.

Re:ssh2 keys?

[Trogre]

Uhhh - with ssh2 keys and no password all a hacker needs to do is gain access to your workstation and they've got your keys and can get into the servers. Do you really want debian.org to rely on the security of every single dev box out there?

A better solution: Use both.
Keys and passwords.

WTF?!!!

[linvir]

"An investigation of developer passwords revealed a number of weak passwords whose accounts have been locked in response," Schulze wrote.

An investigation? Doesn't it a long time to bruteforce properly encrypted passwords? How did they carry out this 'investigation'?

Can somebody please cure me of my chronic ignorance?

Re:WTF?!!!

[Changa_MC]

If you have the ability to allow infinite logins and attempt a scripted dictionary attack on the server (since it's your server) you can crack most weak passwords in a very short amount of time. That's why they're called weak passwords after all.

Re:WTF?!!!

[afidel]

You don't allow infinite logins, that would take way too many system resources and be too slow. You run a password cracker against the hashed password database directly =)

Re:WTF?!!!

[WilliamSChips]

There are programs that take shadow files and from there find the really weak passwords.

Re:WTF?!!!

[linvir]

What I'm most surprised by is that there's no weak password detection during account creation:

Your stupid password is too fucking weak. Try again, and this time try not to be such a failure.

I mean, if they already wrote a script to identify weak hashes, surely it's not too huge a modification to run it on individual hashes before they're sent off to the database or /etc/passwd or wherever?

Re:WTF?!!!

[geminidomino]

What I'm most surprised by is that there's no weak password detection during account creation:

Depends on the system. On Slack 10.2:

thorr:~$ passwd
Changing password for ####
Old password:
Enter the new password (minimum of 5, maximum of 127 characters)
Please use a combination of upper and lower case letters and numbers.
New password: 12345
Bad password: too simple. Try again.
New password:

Probably not abusive enough to someone who really IS using Spaceballs'-level passwords, but it checks.

Re:WTF?!!!

[afidel]

In fact doing so on Debian is easy. You just have to add "password required pam_cracklib.so retry=3 minlen=12 difok=3 lcredit=0 ucredit=1 dcredit=1 ocredit=2" or similar to the files in /etc/pam.d/

For more info on pam_cracklib see this site.

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:WTF?!!!

[Daytona955i]

It's actually very easy, especially if you are the owner of the box to run a dictionary scan against the passwd file. (Or hopefully the shadow passwd file) There is a program that has been around forever called Jack the Ripper that will scan your password file looking for weak passwords. Some places routinely scan their systems with this tool and then email or deactivate any users with weak passwords.

It's really not that hard or time consuming. Now it would take quite a long time to figure out a good password (ie. one not based on a real word having letters and numbers and upper/lowercase combinations). That's why weak passwords are discouraged, because they are easy to find in a password scan.

Re:WTF?!!!

[someone300]

They may have added the cracklib module into the PAM authentication chain making anyone with an insecure password unable to log in.

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:Secure Passwords lead to Insecure Passwords

[bavodr]

Absolutely. I can't agree more. There is an article that goes slightly deeper into this subject:

http://www.cerias.purdue.edu/weblogs/spaf/general/ post-30/ (Security Myths and Passwords)

Re:Secure Passwords lead to Insecure Passwords

[Elliot Anderson]

I found this was one of the most annoying things about attending Ithaca and Bracken Ridge TAFE. To just log in quickly to print something before class meant having to take half the lunch hour to do such a simple task.

[L]Users are the weakest link

[n3v]

This is a reminder on the more people with access to something the more the risk. Also, passwords aren't meant to be simple.. Get /Rh4d wiF 1t M4Yn3..

When I was just a kiddie people used to crusify me for my 3wh34t|\|3$$.. At least I was fast at it! I even had a cutom script for Procomm Plus to translate all my shit.. By that time I learned how annoying it was though ;p
Wow.. that was like 10 years ago.. Doh!~

Good for passwords!

FYI- If you can't think of a not-so-weak password, use a sentence you know and use the letters you remember..

or..

Hit yo-self wit da clue bat ;p

lol.. too much drinkin today me thinks..

Re:[L]Users are the weakest link

[cyclomedia]

re: sentences

for long (but alpha-only) passwords you could use song lyrics, though i'd pick an obscure 30s country/folk group that your dad forced you to listen to on long car journeys when you were growing up and is firmly etched into your brain.*

You know, something like: jimmytookthecattletothemarketplaceonadampanddreary morning

* but not Wayne's War of the Worlds, surely everyone was forced to listen to THAT!?

Re:So?

[Anonymous Coward]

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

So what is your password?

[helioquake]

iforgot /my god, I don't know how many times I saw that password used by my network users...

Re:Passwords

[Anonymous Coward]

By running cracking tools against them, of course.

Re:12345

[kevlarman]

Wait, thats a bad password?!? I have to go change the password on my luggage

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

more security?

[treak007]

You would think that Debian would take some extra steps to secure their systems, or at least make sure their developer's passwords were secure enough. For example, I know that while some websites only have a password security meter, some sites, I think I saw this on gmail, will not let you set a password that registers as weak in their password strength meter.

I think that Debian needs to learn from this mistake and start making some serious changes. There are a lot of people running Debian linux distros that are now vulnerable and this includes businesses depending on Debian's security. You would think that something this serious would be better protected.

Re:more security?

[the.metric]

The machine in question wasn't security.debian.org and it wasn't a distribution machine either. I'm pretty sure it was an old development machine, with no access to anything important, so the only real major concern is whether the same password was being used anywhere else (which could very much be possible).

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

[mikek3332002]

They probably used a dictionary attack and found out various passwords. They dictionary would be things like the %username%, password, asdf1234, admin, root, apple, hello ...
This can be done very fast compared to brute force.
What the script does it gets the word to guess hashes it the same way as the password does (eg SHA-1) and if they match you have the password.

Re:Passwords

[sholden]

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

Re:Passwords

[l3v1]

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

Oh yes, there is, and he's got +5, so extrapolate.
Not even funny.

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

But...

[XanC]

Doesn't that mean that if somebody should somehow get into my desktop, either physically, over the network, an old hard drive, etc, and grabs my key, he will have access to every single machine I can access? And I'd have to make a change on each one of those systems?

I'd really like to switch to keypairs for authentication but that seems inherently dangerous. Am I missing something?

Re:But...

[smash]

You can password protect your keys.

Yes, if someone nabs your key, it's a risk. The password will slow them down however, and if you notice that you've been r00ted and suspect you've had a key stolen, you should generate a new pair.

Also, what i used to do at my previous employer where i used keys, was store my private key on my USB memory stick, and only plug it in when i'm likely to be using it.

That way I can carry it with me, and someone needs to steal it, then know what it is, before they can use it :)

If you only allow logins to the machines you access from ONE central machine (eg, your workstation) and then secure that workstation's private key (eg, on removable media, or a well firewalled/well secured machine that doesn't allow public access), you can reduce the risks.

Of course, the private key is gold though. Password protect it, and as soon as you suspect that it's been stolen, you should generate a new key-pair.

Hope that helps... :)

Re:But...

[smash]

One thing i forgot. If you suspect your private key is compromised, you should of course ALSO tell anyone who uses the public-key half of it (ie, any admin of a machine you've sent your public key to) to revoke it's access.

Re:But...

[smash]

If someone finds out your password (and you use it for a lot of remote systems), you need to change it on all those remote systems. In this respect, a public/private key pair is no different... :-\ You'll need to install/send the new public key to each system.

Re:But...

[XanC]

Thanks for your replies; they've got some good usage tips (I hadn't considered password-protecting the key!). One of my main concerns was that while I memorize my password and it is not stored in the computer at all, the private key is. But if there's a password on the key, that's close to the best of both worlds.

And you're right, of course, that a compromised password and a compromised key both require remote systems to disable access for that token. Of course, one is supposed to use a different password for every system, which doesn't really have an equivalent in the private key..

Re:So?

[Otter]

Please mod up, print out and tape to my sysadmins' foreheads.

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

Even scarier was the training class where the instructor *told* us to trivially rotate passwords!

(The one thing I'd add is that the idea that adding complexity can't hurt is completely misguided. Every new chore you add to password maintenance means that many more passwords on a post-it under the keyboard.)

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

[chemaja]

Just curious, to which OS did you switch?

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:Keys need protection as well

[maxume]

Because he was already looking for a reason and this one was convenient?

Re:So?

[1u3hr]

If a password is so secure that it can't be guessed, then why change it?

They're assuming a decay of password security; that a proportion of people will write them down on odd bits of poaper and lose them, that they'll reuse the password in another context and have it spied out, keylogged, etc. Changing the password cleans up these leaks; unless you're just incrementing as above. If I was cracking and a stolen password failed I'd use it as the seed of an attack.

Hate changing my password every 30 days

[kullnd]

Being that I work on systems which have a government security clearance requirement, passwords on our networks have a few enforced rules..

As a system admin and user however, I really do not believe that the rule of changing passwords, especially when combined with a rule that says you can not use the same password for the next 10 changes, is really a bad idea. I have always used very hard to guess passwords like hcwlcd3cm28MP (and no, this is not a password I use ;) .. Problem is, using passwords such as this can get VERY confusing if you have to keep changing it, especially when you start having 6 passwords like this in use on various systems because some of them make you change at different time schedules. Chances are that the average user is just going to start using stupid crap like "LisaMarie89" which happens to be their daughters name and year of birth because anything else just gets to hard to remember anymore.

IMO, if you setup the rules so that passwords have to be hard to guess, dump the password change requirement, or make it so that it is extremely rare and so that a few passwords can be recycled.

Be interested to hear how other admins feel about this.

Nice reporting!

[MavEtJu]

Debian locks out developers after server hack

How much more useful would have been the headline Debian closes accounts with weak passwords?

slashdot biased ?? naaaah

[cosminn]

Some lady has a weak password and her Windows box gets owned, MS sucks, Windows blows (now the fact that she _does_ run as an Administrator doesn't help).

_developers_ working for one of the most popular open source projects have weak passwords, there is a _kernel_ exploit, and people defend it still.

FYI I run Linux, OSX and Windows on my machines, but common...why can't we all just get along and admit there are problems with software regardless of the company, mdoel etc. ::waking back up to reality::

Re:slashdot biased ?? naaaah

[ultranova]

Some lady has a weak password and her Windows box gets owned, MS sucks, Windows blows (now the fact that she _does_ run as an Administrator doesn't help).

Ladies. Plural. After all, new security problems and viruses for Windows are found constantly. That's why Microsoft sucks and Windows blows.

_developers_ working for one of the most popular open source projects have weak passwords, there is a _kernel_ exploit, and people defend it still.

Debian gets hacked. Debian last got hacked three years ago.

FYI I run Linux, OSX and Windows on my machines, but common...why can't we all just get along and admit there are problems with software regardless of the company, mdoel etc. ::waking back up to reality::

Of course there are problems with all software. However, Microsoft software tends to have a lot more problems than non-Microsoft software.

An eggshell and a two-meter thick wall of titanium-reinforced armor-grade steel are both breakable, but claiming that this makes them similar is misleading, to put it nicely.

Re:slashdot biased ?? naaaah

[squidguy]

Honestly can't believe why you marked this guy down for trolling. He has a point, even if it is weak. If this were a windows vul the majority of slashdotters would be all over it, and the most common statement (after windows sucks) would be how if M$ were open-sourced none of this would have happened.

Fact: (nearly) all software has bugs...some worse than others...independent of platform or development model.

Re:slashdot biased ?? naaaah

[LordLucless]

When was the last time you saw a Slashdot article blasting Windows for a user having weak passwords?

Re:slashdot biased ?? naaaah

[Intron]

Remember Windows 95? If you forgot your password, you could just create a new account and log in anyway. Didn't MS Bob allow you to just change the password if you forgot it? We could blast MS about users with weak passwords, but it would be too easy.

Having a thousand eyes...

[patio11]

... means everyone gets to see your machine compromised?

Non random is dangerous...

[cloricus]

Agreed. Until last week we used out right strings for our sandbox users passwords on servers and test servers (syntax username12345). That was of course before a friendly Windows script kiddie used a dictionary attack against them and in a stroke of luck the username they got was one of the sandbox accounts and their dictionary just had a huge list of username, username1, username12, username1..6. Luckly we had no out standing security flaws and that the sandbox accounts were indeed sandboxed though poor Undernet got an extra 2mbit to the face for half a day while we tracked down the problem and stopped it.

So using strings that are non random are just an out right bad idea because even a dictionary attack that is large enough can get them and then incremental on top of it is even worse because it gives you a false sense of security. If the attacker knows it is company policy to =/- 1 every month they will just try the pw +/- 1 per month old the pw is. So yeah it is just a bad idea all up when put in userland.

Re:Passwords

[TakeyMcTaker]

If they have access to the server root, being administrators, they have access to the *encrypted* versions of the affected password files. From there, it is trivial to run Cain, or a similar decrypt tool, on the password list, to see which passwords get decrypted fastest. You would be amazed how fast even 9+ character long, multi-case, special character encrusted passwords can be decrypted with some nice Rainbow Tables on modern *desktop* hardware, not to mention a relatively cheap Beowulf cluster, or even a relatively simple multi-PC distributed brute-force crack. Think CRAKI-at-home. Bad passwords, like dictionary words, proper names, SSNs, and dates, can be decrypted by the most limited tools on 10 year old hardware, in a matter of minutes. Decent hardware and tools can reduce that to seconds.
        You have to assume any passwords on the 'Net, encrypted or not, can be sniffed -- copied whole as they travel, with no way to detect who did the sniffing. If an encrypted password is sniffed, the same tools an administrator can use to weed out weak passwords can be used by crackers. That's why even encrypted password tokens should be further encrypted by VPN or SSL tunnels, which have other nice features to prevent Man In The Middle, and related address-spoof style attacks. These encrypted tunnels should always be used on anything other than a very physically secure LAN (and no, drywall does not make a LAN secure), and even on a LAN the overhead is low enough to use SSL anyway. I personally use a minimum of HTTPS around any Internet traffic that is intended for private use.
    Likewise, e-mail is never "private" unless you use PGP, and phone conversations (VoIP and PSTN, Skype included) are never "private" unless you use something like Zphone on both ends -- as AT+T and NSA have taught us all. Who knows when the NSA will approach Skype?...

Me Takey

Time to get those Deb tokens out!

[coralsaw]

These tokens that banks give out, they cost less than $20. Type your pass, put the one-time token number in and on you log to your Deb dev box.

I'd be amazed if there's only one compromised distro dev box out there. And I'm not only talking Debian.

Sleepers ahoy...

FreeBSD.org servers don't use passwords...

[mi]

They rely on the slightly more secure method of ssh keys.

Re:FreeBSD.org servers don't use passwords...

[Tony Hoyle]

... which commonly don't have passphrases attached (and there's no way to verify whether they do either without getting hold of the private key). Whats more is you only have *one* private key so if it is compromised access to every server you use is wide open.

This makes them *less* secure in many cases - at least with passwords you can have a different password for each server.

Re:FreeBSD.org servers don't use passwords...

[Marauder2]

And what is to prevent you from having a different key for each server? There are plenty of people who do exactly that.

There are plenty of people who use the same weak password for every server... with that password on a note stuck to the monitor. If that password is compromised "access to every server you use is wide open."

The fact of the matter is, many weak passwords can be easily guessed and brute forced. a 1024bit key is realistically impossibe to brute force or guess, it would have to be stolen.

A GOOD ten character alphanumeric password could be at best relative to a weak 80-bit key (10bytes). It's actually less since not all ASCII codes are valid password characters (it's safe to assume only the standard 94 keyboard characters). Additionally, most users do not use truly random passwords which would further weaken the strength.

It is easy to intercept a password with any plaintext protocol (many IMAP/POP servers are STILL not set up to use any sort of encryption). It is virtually impossible compromise a private key without compromising the keyfile itself either through some form of social engineering, or by compromising the network or physical security of the device that contains the key.

Re:FreeBSD.org servers don't use passwords...

[smash]

*can* do.

I'll bet dollars to donuts that maybe 1-2% of users actually *do*

The downside of passwords compared to keys is that they're many many times easier to brute force...

Re:FreeBSD.org servers don't use passwords...

[mi]

This makes them *less* secure in many cases

No, because one will first need to break into the legitimate user's own computer. Which is not even always online. It is possible, but harder than getting his (easy to guess) password.

at least with passwords you can have a different password for each server.

You can have multiple keys too, even on the same client. People even use different ones for different tasks (full logins vs. `cvs commit' vs. cvs-readonly operations). And, as you mention, these can be password protected.

This is not an argument, ssh-keys are better than simple passwords. By how much is another story...

Not dumb, just unaware of options...

[patio11]

He's thinking "Hey, how would you know whether the password was insecure or not without looking at it?", and has correctly identified the fact that you shouldn't be able to work backwards from a hash to the password. However, he failed to take into account the fact that you could come up with a list of N bad passwords (say, 40,000 words pulled from a dictionary or something similar) and check them against all the passwords you have in O(N+M) time, where M is the number of accounts you need to check (constant time to hash a password, constant time to mark that hash location as "bad, collides with known bad password foo" in a hash table, constant time to lookup each password hash within your hash table and test for badness).

You could also do an O(M) search by taking any suite of password hacking tools you want, allocating them X amount of processor resources (say, 5 minutes CPU time each), and then letting them loose. Anybody whose password gets broken gets locked. In previous discussions some folks have noted that their organizations perform this check on a routine basis.

Re:Not dumb, just unaware of options...

[cnettel]

With salted hashes, your O(N+M) number is replaced by O(NM). Kind of the point of salting the hashes.

Re:Not dumb, just unaware of options...

[kasperd]

you could come up with a list of N bad passwords check them against all the passwords you have in O(N+M) time

No, you cannot do that. Each password is hashed with a different salt for exactly this reason.

Re:Not dumb, just unaware of options...

[patio11]

Ah, you're right. Its unlikely to be a practical deterrent to this method, though. N is so much greater than M that its effectively still O(N), just with a slightly nastier constant. Sure, if you have 100 developers it takes 100 times as long... but you were already burning through a couple tends of thousands of words to check, and since the process doesn't have to be realtime you've got all the time in the world. As long as you don't go polynomial with regards to N you're fine-and-dandy.

Re:Not dumb, just unaware of options...

[Tony Hoyle]

..and the salts are stored in the password string.

salts don't do shit against that kind of attack. All they do is stop people trivially recognising that two people have the same password.

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.

[OT] poor naming decisions

[Apro im]

People really need to think about how their product names parse when the words are run together and all one case. This is a particularly bad case, because there is only one way to parse "keepass" into real English words, and it's not the way they wanted. I'm sure they liked the idea of sharing the last letter of the first word with the first of the last, and sometimes it works. Other times, though, you end up naming your project "Keep Ass"

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

tell them to get ...

[jonathan_95060]

Password Safe.

http://passwordsafe.sourceforge.net/

It was only after I installed password safe that I began using strong passwords on more than just a few accounts.

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

[micheas]

Interesting that Debian seems to know that passwords were "weak". Only 1 poster here seems to have picked up on that curiosity. How do they know after the fact that a password was weak?

As mentioned above, probably John the Ripper is how the found week passwords. (not knowing this removes some crediblity to your comments as that tool has been around for about a decade. and programs like crack and pwc have been around even longer.)

Running an old kernel is against their own recommendations is something that is a little hard to understand.

Finding weak passwords is trivial.

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.

Re:Oh the irony!

[KiloByte]

Say what you want about microsoft, but I dont think they have ever had their asses handed to them by hackers.

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.

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

How do they know which are weak passwords?

[nettdata]

I find it interesting that they would know what accounts have weak passwords... does that mean that they are storing them in clear-text somewhere? If not, then how do they know?

The sites we build and administer only store hashes of the password, or something similarly obsfucated.

But yeah, the public-key ssh2 access previously mentioned seems like the only "proper" method for their access.

Oh well... hindsight is 20/20.

Re:How do they know which are weak passwords?

[graemecoates]

I find it interesting that they would know what accounts have weak passwords... does that mean that they are storing them in clear-text somewhere? If not, then how do they know?

The sites we build and administer only store hashes of the password, or something similarly obsfucated.

But yeah, the public-key ssh2 access previously mentioned seems like the only "proper" method for their access.

You run something like John the Ripper and have a go at trying to crack the password file yourself as a sysadmin using a simple dictionary attack and the variations it offers. There is even a cron job that can be run to periodically look for the weak p/ws on the system.

Having key based authentication is a good increase in security (prevents brute force attacks), but it relies on the user keeping their key safe, having strong key passwords, etc..

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.

[dnoyeb]

How do they know the password is weak?
Did they ask the developer if his password was weak?
Did they try to crack it?
Do they know it?

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.

Re:Your new Debian password.

[Lennie]

Then it wouldn't be a save password to use.

Re:Your new Debian password.

[Copid]

What if someone's "strong" password just happened to have the same hash as a weak one?

Answer 1) Then they're VERY unlucky.

Answer 2) Their password is still bad because an intruder typing in the weak password still gets the OK from the system.

How many of these occurences do we see in Linux?

[jotaeleemeese]

Few and far between.

In Windows? Well, at some point is not even news (MS just stopped support to an estimated 70 million of pre W2K users, talk about a mega insecurity incubator).

WIndows security is a joke that leaves a bad after taste in your mouth. Even their "most secure" rubish relies on putings bit and pieces on machines' registry where it can be easily harvested. And their security model has been broken for years.

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

Re:Chip and Pin

[Jeff DeMaagd]

I have to deal with a credit card merchant account and I was trying to convince the salesman that the CCV2 code can be stolen. He said you had to have the card in your posession in order to know what it was. Grrrrr. I really didn't have the patience to explain that some web sites are poorly designed in how they handle database security.

Re:So?

[Joebert]

... print out and tape to my sysadmins' foreheads.

Seems to me that taping such information to sysadmins' foreheads would be alot like placing a post-it note with password hints on the edge on the monitor.

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?

Re:So?

[datajack]

If a password is so secure that it can't be guessed, then why change it?

Because often password compromises don't come about from passwords being guessed. Passwords may be stolen in many other ways (social engineering, man-in-the-middle, brute-force against a password file backup, dumpster diving for the post-it with it written down on, etc. etc.).
If an attacker has your password, they're not likely to let you know about it. Changing your password regularly (no matter how 'strong' it is) limits your exposure.

People can be idiots

[ShyGuy91284]

How hard is it to make a couple a character alpha-numeric passwords and dedicate them to memory? After maybe a week with it written down in your wallet for reference, you'll have them memorized and have no problems!!! Then you just have to worry about yourself muttering them in your sleep....

Re:People can be idiots

[Cro Magnon]

A couple of alpha-numeric passwords is easy. 50 different alpha-numeric passwords is hard! And each of those 50 have different rules for what they can be, and how often they have to be changed.

Password policy: OK, but user policy?

[gedeco]

He does one choose users, aka developpers on debian?

If for instances someone wan to be a debian developper, creates his account Bill.Gates@debian.org choose on purpose a weak password (does not matter) and then has been in contact evil@hacker.org who managed to get the password.
In case Bill Gates would obtain a developper status, I wouldn't wonder he would open source his password to any hacker arround.

But seriously, no FUD: How do they work to trust their developpers.
I can't imagine I'm writting a little tiny app, knock on the debian door and they would open it. This is user trust policy.

Re:Password policy: OK, but user policy?

[tao]

That's what the Debian New Maintainer process is for. Sure, with some social engineering and a display of good package maintainership you can get an account, but I suspect few script-kiddies would be willing to spend 6-8 months of tests and waiting just to get an account on a Debian machine. Oh, and since all Debian developers are *required* to have a GPG-key that's been signed by a Debian developer, it means that at some point in time they need to show their passport to a Debian developer. Not exactly the best way to sneak your way in...

Re:Password policy: OK, but user policy?

[kbmccarty]

He does one choose users, aka developpers on debian?

But seriously, no FUD: How do they work to trust their developpers. I can't imagine I'm writting a little tiny app, knock on the debian door and they would open it. This is user trust policy.

You raise two different questions: how can Debian Developers be trusted, and how can the code that ends up in Debian be trusted.

For the first case, there is an extensive New Maintainer application process. This includes tests to see whether the applicant knows what s/he is doing, questions to see whether s/he understands and agrees with the philosophies of the Free Software movement, and a GPG key check to make sure that at least one current developer has met and verified the identity of the applicant. Additionally the applicant is supposed to have a history of doing good Debian work. At least two individuals, an Application Manager and one of the Debian Accounts Managers, independently research the applicant. (Only the DAM knows how extensive this research is but I have reason to believe it is quite thorough.)

For a package maintainer who isn't a Debian Developer yet, all his/her work goes through a developer sponsor who reviews it carefully. Only the maintainer's source package is used (not binary .debs), and it is rebuilt into .debs by the sponsor before upload. The sponsor takes particular care to ensure that the upstream source code ("orig.tar.gz" file) used by the maintainer is identical to that available from upstream's web site. Since the sponsor takes the final responsibility of uploading this person's work, s/he has an incentive to make sure everything is OK with it.

This ties into the second question. Even for a package uploaded by a Debian Developer, there is first supposed to be an Intent To Package announcement posted on the debian-devel mailing list (here's an example; notice that this isn't just a rubber-stamp procedure; the example I gave led to a lot of discussion). The developer is expected to review the source code, as much as is reasonable, to make sure there are no trojans built in. With each new revision by upstream, the developer reviews the full diff between versions.

Of course neither procedure is foolproof. Someone with enough dedication, intelligence, and malevolence could manage to get through the New Maintainer procedure and do what you suggest. Or an upstream that was clever enough to write well-disguised trojan code could trick a developer into uploading it into the Debian archive. (There was actually an example of this happening, though the trojanned code wasn't harmful; see this thread. Needless to say this didn't help the upstream author's New Maintainer application.) But these are risks in any software project, not only Debian and not limited to Free/open source software.

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

[TeknoHog]

If you manage to have multiple Capital words in the sentence, your password gets stronger.

It's even stronger if you know how to capitalize...

Today i ate two buns for breakfast! -> Tia2bfb!
And today: A new password for my debian account! -> At:1npfmda!

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.

Re:howto: strong passwords

[pyhack]

Great idea!

please ask simple simon what's on radio dial one -> password1

Ha! MS did it first!

[The MAZZTer]

http://www.sysinternals.com/blog/2006/05/power-i n-power-users.html

Local escalation vulnerabilities have long been a feature of Microsoft Windows!

But seriously, that's a good article about why it's not a good idea to give other users Power User privileges. It might help with securing a system too.

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

Re:Again?

[wobblie]

thanks for straightening that out ... I frankly can't believe sysadmins are rolling their own kernels for public boxes, really. Damn.

FYI

[weierstrass]

http://en.wikipedia.org/wiki/Humour

hth.

Re:So?

[Antique Geekmeister]

Passwords that are infinitely strong against guessing will instead be monitored when even a careful person accidentally uses it for FTP, telnet, or an unencrypted IMAP or POP connection, or when some exploit gets put in place on the servers to report other people's passwords.

If you don't believe that this happens, you don't remember the SSH crack that happened some 5 years ago, where companies all over the world had their SSH daemons replaced with one that logs and reports user's local passwords.

Re:Passwords

[tehcyder]

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

You must be new here.

spelling

[BitterAndDrunk]

Only because you missed by a mile and perhaps would want to know the proper spelling. Not trying to be a douche here, just share knowledge.

Permutations is the word you were looking for.

Re:spelling

[BecomingLumberg]

I'm sticking with my 7am excuse like I did with the previous post. I was only 10 minutes into my coffee.

no problem :)

[BitterAndDrunk]

I'm really not a spelling-nazi! No excuses necessary.

Simple answer

[SIGBUS]

Uh, maybe because I was using sendmail instead of exim?

FWIW, I switched over to CentOS - which had a fix for the sendmail bug the same day it was announced.

Is Debian being targeted?

[rdmiller3]

Is anyone else wondering why someone would be trying to break into the development server of the Debian distribution?

Maybe someone is trying to "own" every Debian-based machine by slipping their own "minor bug" into it undetected.

This is where distributed, public-key-signed version control (like in monotone) would save the day. No one would be able to sneak something into the version-control archive because all change packets are uniquely identified and signed with a developer's public key.

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

Re:So?

[Antique Geekmeister]

And use it for other sites: People often only change their password at the site where they're forced to, but leave it intact elsewhere, begging to have their accounts invaded on those other machines.

ssh blocking, passwords are necessary

[PhYrE2k2]

disable password based ssh authentication

That will be _SO_ helpful when you lock yourself out of your own system.

and force everyone to use public/private key authentication

Will be great if your hard drive fails, keychain with your memory key gets stolen, or you're not at your office computer.

Rat our passwords all you want, but combined with throttling/limiting/detection on the server passwords are about as secure as they come. Note my qualifier here. There are tons of scripts, and I run them on all of my servers, that will parse /var/log/auth (or whatever you have set up) and find the failed password or invalid user strings. Five-Ten failed passwords and your IP gets denied for a while (/etc/hosts.deny or iptables- your pick).

These scripts are readily available on the net, and are easy to make as well.

This will protect brute force and easy passwords. Now your users just naming their password after their dog will always be a problem. Requiring complexity (a number or mixed case) will be key to securing those passwords, although I'm sure are directly correlated with an increase in support calls.

-M

Time-out lockout

[The Conductor]

My workplace does that lockout after short time-out...it doesn't do much when you have to tape the password on the monitor. It also makes it impossible to gracefully shut down the machine when someone else is logged in. I think the practice is a result of somebody reading Sarbanes-Oxley and freaking out. Can't blame 'em too much; if I had to read SarBox I probably would freak out too.

Good passwords and ssh keys....

[WgT2]

It would help if they required SSH keys plus strong passwords.

Passwords By Themselves Are Weak

[beringreenbear]

This is simply a fact of life. Sure, you can come up with a really long and hard to guess password, but beyond a certain point, you end up with something obnoxious, hard to remeber, or something that simply gets cycled about a bunch of places.

Real (cheap and reasonably strong) security requires a mix of keys. For example, a synchronized pseudorandom number generator, a hashed passfile, followed by the standard text password. Still not perfect because the pseudorandom number sequence can be cracked and the hashed passfile (both stored, stored, say, on a USB drive) can be compromised, but a layered approach provides the best blend of ease-of-use and security.

The problem is (especially on a free project like Debian), how do you pay for the (physical) keys and who issues them? Can it be done without unfairly creating a barrier to participation?

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

Re:Passwords

[PitaBred]

It's easier to require developers to have secure passwords than to force them to run things like fail2ban on their personal machines. If the attacker compromised the developer's machine, then used that info to log into the main debian server, well... they're still boned.

Re:Oh the irony!

[cranos]

Umm actually no, my rebuttal would be the large chunks of windows 2000 source code that was ripped out of the internal MS network by a hacker. Would that be considered "having their arses handed to them"?

Blame the Developer?

[bill_mcgonigle]

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?

Why would you assume there's a stupid developer who can't figure this out? Isn't it more likely the prototype system didn't use an escape mechanism and the developer had one on his TODO list and his manager told him to FUTURE it?

Occam's Razor if you ask me.

Re:Oh the irony!

[dave1g]

I dont see why I was modded troll, I have no hate for Debian nor love for microsoft. It is simply a funny news story. Does anyone know if the exploit already had a patch? And how long ago was the patch released? And what is Debians excuse for not patching?