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

[Anonymous Coward]

I prefer the wonderful feeling of randomly generating a password and storing it in a securely encrypted file.

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

[dupper]

The miserable thing is that I'll never be able to explain to people the genius of my passwords. Well, maybe on my deathbed.

Re:Ah. balance

[Anonymous Coward]

Wow. I can feel the love in here!

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

[Anonymous Coward]

That's funny, that's the same password we use on the keypad for our building.

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

[Anonymous Coward]

Is your password Twfeomtphtgbetr?

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

[Anonymous Coward]

Za#rust#tes2#r#5

That is my password, of course I ommited some characters (the #s). I generated it in an online random password generator. I use it in my email account, I also use the 8 first characters or the last 8 characters to different logins trough the web.

I had another password which was very weak (just a simple anagram of aaaakkort but after using it for 5 years I toought I needed to change it for somethign more secure.

Oh, and btw I dont use any of these passwords in my slashdot account, I have another password (the one i used when I entered the WWW first time back mid 90s.

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

[Anonymous Coward]

Your digits consist of 0 and 1, right? :)

Re:Ah. balance

[Anonymous Coward]

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.

OpenSSH was developed by the OpenBSD people for tada OpenBSD. If you want PAM support the code is out there, go for it.

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

[Anonymous Coward]

First let me say Theo is a sociopathic turd. Now that that is out of the way and nobody will think I'm just trying to defend said sociopathic turd:

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

Why does Theo have to do anything? Seriously. The source is out there. It's under a free license. Fix it yourself. At least that is always the story you hear from the Linux camp. There are more pacakges that run only on linux than on all the other free unixes combined. And it's not even shit that requires specific linux technologies that don't exist anywhere else, it's often just tied to linux-isms that, as much as anything, are the result of NIH syndrome in the free software crowd.

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

[Anonymous Coward]

I remember that in a past life, in a galaxy far, far away I was telling a guy from a large mobile phone company why all the passwords had to change for the testing accounts on our server, I used the example that there was even one account that had a username of "1" (don't ask why we allowed it in the first place). Of course he would have to be the one who actually HAD that username. Oh well...

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

[Anonymous Coward]

Most of passwords are of the form:
Thispasswordis4myworkstation!
Thispasswordis4mylaptop!

Easy to remember, very hard to guess.

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

[Anonymous Coward]

Once you are in full control of a user machine it is game over as far as any resources it accesses are concerned.

Not if you use a one-time password system like S/Key (aka OPIE).

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.

Actually they have technical reason(s) for not liking PAM.

Re:Ah. balance

[Anonymous Coward]

Protocol 2
LogLevel VERBOSE
PermitRootLogin without-password
PasswordAuthentication no
ChallengeResponseAuthentication no
X11Forwarding yes
UsePam no
ClientAliveInterval 60
ClientAliveCountMax 30

There is no danger of allowing a root-login in ssh if everyone needs to use their own personalized rsa/dsa root-key to log in. The effect is exactly the same as a use-login followed by an su. The biggest problem with ssh and PAM is that there are so many darn switches that impact security (negatively) that it is very easy for an inexperienced admin to inadvertently punch a big hole into the protection.

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

[Anonymous Coward]

"belongs to the realm of OpenBSD and should have nothing to do with OpenSSH. If OpenSSH is to really support linux"

Apologies for the caps, but so many slashdot readers (and linux users in general) don't know what the fuck OpenSSH is.

OPENSSH IS PART OF OPENBSD.
OPENSSH IS NOT A SEPERATE PRODUCT/SYSTEM/THING.

The only reason it is so widely used was that the OpenBSD developers put in a bit of effort to make the SSH bits modular - so they have been easy to port to other systems. "OpenSSH" has always been the OpenBSD SSH, which other people have borrowed.

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

[Anonymous Coward]

Not exactly. In this case, having one password and one root exploit was equivalalent to two passwords.

Re:Ah. balance

[Anonymous Coward]

Yes

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

[Anonymous Coward]

Thus crippling the open source community~

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

[Anonymous Coward]

The kernel dev cycles are different than higher ver == newer release, but it is true within each sub-version. 2.6.16.24 was released _after_ 2.6.17.4. The patches for [this|these] vulnerabilit[y|ies] to 2.6.16.24 [was|were] probably just [a|] backport[|s]. ;-)

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

[Anonymous Coward]

Umm, what's an uppercase number look like, !@#$@%#?

I also didn't know that sweedish was the default. That's cool, bork!

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?

Re:libpam-cracklib

[Anonymous Coward]

I totally agee. I work for a 'security' company(Symantec) and they limit the paswords to 14 characters. Ummm, wtf. Sounds to me like the network 'admins' specifically want to keep LanMan hashes. STUPID!

Re:libpam-cracklib

[Anonymous Coward]

As long as it isn't easily guessable, why does it need to be particuarly strong with account lockouts in place?

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

[Anonymous Coward]

"Asdf2345"

Well thanks a lot, asshole.

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

[WilliamSChips]

Because the exploit had nothing to do with the OS. Most Windows exploits are OS exploits.

Re:I wonder...

[The Bungi]

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

Re:I wonder...

[WilliamSChips]

Oh. Either way, I mostly use FreeBSD now anyways. Also notice how Linux has been patched, no having to worry about 30-day cycles like with M$. 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.

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

[Anonymous Coward]

Most likely because in this instance the kernel vulnerability couldn't have actually been used if it hadn't been for some idiot using a common easy-to-bruteforce password. In other words, you had to be already inside to be able to have a chance at causing more damage.

Windows on the other hand just sees that your an intruder, and kindly opens to door to come in.

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

[Jessta]

because mostly everyone of slashdot is an idiot.

Re:I wonder...

[Anonymous Coward]

I can only agree...

It's actually really sad to see the attitude towards MS not being on a realistic level here.
This means that comments on MS on /. cannot be seen as credible, which makes the whole thing less valuable.

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

[Anonymous Coward]

Waah! My MANHOOD (or lack thereof) has been damaged! I am DAMAGED GOODS! Waaah!

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

[Anonymous Coward]

So you're like a rebel without a friend, right?

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?

[Anonymous Coward]

It's true, there is no panacea. Most large scale environments I have been in (US academia) end up following the policy of disabling remote password access and requiring public key auth on ssh.

Public keys are entered via some combination of secure websites or email+telephone calls w/ multifactor authentication or in person visits to the IT staff office. This is because there are too many insecure protocols in use in the LAN and WAN (think a large University campus) where username/password pairs can be sniffed and then tried against SSL or SSH protocols that allow tunneled passwords. Too many users use the same pair everywhere they can.

I think it is more common that someone is doing a brute-force attack than an attack targeted at a single user, which is what it takes to acquire someone's properly stored private key. Of course, if you have screwball users who copy their private key files into every system instead of using agent forwarding, or who put them in NFS file servers with untrusted LAN access to said filesystems, then there really is no proper response except disabling user accounts. :-)

If you want easy security with public terminals/shared consoles, there really is no solution other than smart cards or some multi-factor system like a secure ID token/one time password list AND a memorized password.

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

[Anonymous Coward]

I had a friend who (after obtaining the hashes) managed to brute force all my school's admin passwords(and quite a few student passwords). Admittedly, he found weaker hashes than I would expect debian to have, but the weak student passwords broke in minutes (single processor), and the stronger passwords broke in maybe 100 processor-hours (he hacked together a cluster for this). If you are determined to break a specific password, you can often (this would obviously depend on the type of encryption) brute force a few letters, then based on that make much more accurate guesses on what the password could be (the only reason my password survived this was because he wasn't particularly interested in my password).

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.

Thanks CowboyNeal!

[Anonymous Coward]

To be fair, they'll most likely be let in once everything's back to normal. Of course, they'll probably need to set safer passwords too.

I had to check the browser location bar that I'm still on Slashdot. That's exceptional from a Slashdot editor. Thank You. (BTW: captcha: renewing)

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

Passwords

[RickPartin]

"Due to this, a number of developers with weak passwords have been locked out of their system accounts."

Wait. How did they know the passwords are weak? You mean they actually store them as plain text instead of a hash? Sounds like there needs to be a major security overhaul.

Re:Passwords

[Anonymous Coward]

By running cracking tools against them, of course.

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

Re:Passwords

[Anonymous Coward]

Of course it's plaintext you *... You cand send an e-mail with the subject "I'm a troll and people buy it" at get_me_the_password_list@passwords.debian.org and you will receive all the current passwords. Please include your current password so it can send you the reply.

score 4... yeah right

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

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.

Re:Passwords

[tehcyder]

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

You must be new here.

Re:Passwords

[Anonymous Coward]

I know the following isn't what happened in the Debian case, but maybe someone can help me understand this.

Suppose I use shadow passwords. They are contained in /etc/shadow and that file is owned by and can only be read by root.

Name a scenario where an attacker would run John the Ripper on /etc/shadow and recover passwords without ALREADY having root access on the box in order to read /etc/shadow to begin with.

It seems to me that shadow passwords contained in such a root-owned non-world-readable file mostly solves the dictionary-attack threat--assuming one also locks people out after three ssh login failures with something like fail2ban. (But something tells me I'm missing an attack vector.) Anyone care to elaborate? If I do those two things why do weak passwords even matter?

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.

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

12345

[Alsee]

Sorry, my fault.

-

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

Re:good idea

[Anonymous Coward]

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.

Deploying a common development machine for a high profile project where the compromise of a single account puts the entire machine at risk is just irresponsible.

Let's see

[Anonymous Coward]

You have a system that you need to protect. You have users that you potentially don't know personally. You don't know whether they're aware of good password practices.

How could you be using anything else than public-key authentication?

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

Windows 2003 wouldn't of made a difference.

[Anonymous Coward]

There are plenty of local user exploits aviable for Windows.

90% of the hack was finding a weak password. Once the attacker had access to the system as a user then finding local privilage escalation vunerability is trivially easy.

Compared to physical security:
Getting the password = gaining access to a secure building. Bypassing all locks and alarms.
Executing a local exploit = popping open a cover on a PC and pulling the cmos battery so that you can boot up a knoppix cdrom, reset the administrative password, and then taking all the secure data.

The first part is infinately more difficult/lucky then the second part.

This is similar to the first problem. They got a password and then tried out local root exploits. This indicates a cronic problem.

Probably what they should do is impliment a authentication system that is not wholy dependant on passwords. Something like a PKI.. with signed keys, VPN's, and SSH keys (or whatever) with a certificate authority then backed up with passphrase.

So if a attacker hacks a developer's machine and get the keys then they would still have to get the password. If the hacker gets the password and not the keys then that won't work either.

Doing that would raise the difficulty of getting into a Debian development server by probably a factor of 10.

*gasp*!

[grasshoppa]

Goodness, no! This might push them behind schedule!

What?!

[rea1l1]

Linux can have bugs too?

Holy shit That's the same as I use on my Luggage!

[Anonymous Coward]

NT

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.

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

[Acc7]

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?

Unless Debian is doing something very stupid like keeping passwords in clear text, hashing passwords reversibly, hashing passwords to their original length, or something else equally amateurish(sp).... Then the vulnerability is in fact in the Debian system, in their management's soul, & they have some pretty bad techs...

This sounds like a "no excuses" mistake by Debian, that has been followed by an equally damaging admission of their mishandling of passwords. kind of disappointing actually both are very disappointing......

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

[Anonymous Coward]

Which planet are you from? Please, but please go away! Glad you're not using Debian, the universal operating system of amateurs.

Of course you're not providing access to thousand of developers on a server so you have no idea what you're talking about, but you do it anyway. Weak passwords, compromised hosts, etc. God damn it. A local root exploit? Theirs bash was probably setuid. That must be it!

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

[Acc7]

not interesting. So as an amateur you use Debian? Is that it?

my my my...... why not answer the question?? how after the fact does their "investigation" determine that a password is weak without cracking it, looking in clear text login lists, snooping on their developers as they log on? Point is that they don't know what passwords are if they are properly created & stored securely. But they do know, if they are keeping some kind of an improper record.

So at best if they kew when the hack happened they might know who was logged in. That would give them a shorter list of passwords to try and crack to find the weak ones. Or if they had that logged in list they might have just called each develper and asked what their passwrods were.

But they didn't have that or they could have just locked out the developers that were on the logged at the time.

my my my my isn't forensics interesting

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

[Anonymous Coward]

Read the previous post you refer to. Read the replies... Don't mod this person any higher, please.

If I were a tech who had just discovered a pseudo-important system had be compromised, I'm sure I'd go right to work making it harder for anyone who had appropriated a copy of the password DB to recover any weak passwords. After all, they will take just as long or longer than me, so I might as well get to cracking it myself.

Note I have little idea what the hell I'm talking about, as I don't really fully understand the specifics of what has happened. I do know that anything hashed can be unhashed with a bit of time.

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

[Anonymous Coward]

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

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

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

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

[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:Weak Passwords ?? If they know that ...well

[LordLucless]

First Post: Unless Debian is doing something very stupid like keeping passwords in clear text, hashing passwords reversibly, hashing passwords to their original length, or something else equally amateurish(sp).... Then the vulnerability is in fact in the Debian system, in their management's soul, & they have some pretty bad techs...

Second Post: And I was not knocking the Debian code, just the management errors that led to this particular problem.

see here - take special note of definition 3.

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

[Anonymous Coward]

By leaving us to guess ... well, where do I start? The whole thing happened day before yesterday, and we got notice about it from James just yesterday (tersely, but that's just James), and he explicitly said the cause for the compromise was still being investigated, and to let us know as soon as facts are found. Today, I read Joey's announcement that it's been the PRCTL hole that was just reported days ago. Where exactly was information held back and the door opened for speculation? Seems to me DSA did exactly what they promised to do.

Re: sniffing - login to project machines is exclusively ssh protocol version 2.

Re: weak passwords - Debian uses shadow, and john is the standard method to discover weak passwords. Nothing unusual here from my POV. The 'entirely outside' question touches on whether all logs were wiped clean, and what level of logging was kept regarding ssh logins. If the logs were untouched and logins were logged including IP information, it is possible to trace the intruder back to where he logged in from, and you can assume an outside job if this does not match his usual work patterns.

HTH,

    Michael

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.

Re:Hate changing my password every 30 days

[Anonymous Coward]

I find this REALLY REALLY annoying.

The change passwords every 30 days requirement comes from the good ol' days of multi-user non-inter-networked systems.

Some clever consultant somewhere decided that as it takes (for eg) 3months to brute a password on such a system that it should be changed every month in order to make brute-ing impossible.

In todays internet world this is completely the opposite of what should happen. As pointed out by some many /.ers it makes it hard for Joe "stupid" Public to remember and they end up using simpler passwords which can be cracked in a lot less time with dictionary attacks and/or writing the password down on a post-it note attached to their monitor.

I would much rather have my users choose a secure password they get to keep and learn to remember for 6/12 months.

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?

Re:Nice reporting!

[Anonymous Coward]

You can have your "super secure" password and use it for 3 years and wonder afterwards, what?! How did he knew my password? Or you'll have you own box compromised, or use a server that has been compromised or or or... How many of you use a different password for every account?

I do not believe that the password used for the break in was bruteforced. Simple or not, you'll have to try some combinations before you'll get in. And i still think that they would see such "behaviour" even if scans for weak passwords are made on a regular basis on the internet.

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.

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:Not dumb, just unaware of options...

[Anonymous Coward]

salts don't do shit against that kind of attack.

Jeez what a moron. Yes, salts do protect against this kind of attack. In fact this kind of attack is the reason salts are being used at all.

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

Oh the irony!

[dave1g]

I love it. An operating system distribution was rooted due to a vulnerability in the OS.

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

Of course your rebuttal might be tht they are too busy rooting everyone elses boxes at home.

I love it, in other news, Peter Coors of Coors the brewery, and 2004 Senate candidate was arrested for drunk driving.
The day gets better and better!
http://www.cnn.com/2006/US/07/13/coors.arrest.ap/i ndex.html

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.

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

Re:Oh the irony!

[Anonymous Coward]

i know for a fact microsoft got hacked. seen screenshots of their network & and bcentral customer db.....

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

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?

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:tell them to get ...

[Anonymous Coward]

I've been using Password Safe for about 10 years (long before it was open source). It is one of the best security programs around. Easy to create and recall my 100+ strong passwords.

So Sad

[Anonymous Coward]

As an ex-Debian user this doesn't surprise me a bit. They used to be so on top of things and I was quite happy using Debian as my only OS for 3 years but a few months after Sarge went "stable" things started breaking for me, and on the powerpc port last time I tried (5 months ago) it was impossible to even compile a linux kernel -- and that was Debian "stable"!

That was the last straw, and I switched to FreeBSD on 1386 and OS X on powerpc. The truth is Debian doesn't have a stable release anymore (but it's easier to install than ever, hey!). Damned consumer-oriented focus...I was happy installing with dselect, personally.

I think many Linux distros are becoming basically consumer-grade OSes unsuitable for production or development use, but in Debian's case it strikes me as a particularly sad state of affairs.

SSH keybased ?

[Anonymous Coward]

And especially to counter these problems you can easily setup key-based authentication using SSH. In this case its (nearly) impossible to login to a box if you don't own the private key which corresponds with the public key stored in the users ~/.ssh/authorized_keys file. No key, no access and as such also no password guessing.

Surely these kind of ideas can't be that to come up with, especially after this project has experienced compromises more often ?

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.

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.

[Anonymous Coward]

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

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.

You are wrong on this instance.

[Anonymous Coward]

Software developped by MS has earned its reputation as insecure with steady but sure lack of attention to security issues.

I have witnessed in the last 5 years:

-Complete meltdown of our corporate network due to viruses (we are behnd firewalls, were up to date in MS recommended patches, have fulltime good Windows Systems Administrators and have a corporate virus infrastructure in place. Still no cigar. Why? Because Windows is intrinsically insecure).

-Meltdown of machines due to vulnerabilities related to stuf we don't even use (MS bundles so much rubbish you don't need together that is impossible to remove stuff you don;t need, opening your machine to related vulnerabilities that could have been otherwise easily avoided).

-Hiding of security information on the registry (ask your MS representative where do they store AD private keys).

And so on and so forth.

During the same period our Solaris, Linux (Red Hat), AIX and HP-UX machines have been running happily, some of them with uptimes of 400 or 500 days.

MS got wrong their design, from a security point of view is inferior. Period.

It is high time that MS apologists stop pretending the elephant is not in the room.

It is there, is dead, you can't beat it, and it stinks.

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.

How did they identify the breakin!

[Anonymous Coward]

Guys,

How did they find out it was a user account that was compromised. What tools did they/do they have running that are monitoring there servers?

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.

Re:[OT] poor naming decisions

[Anonymous Coward]

A problem shared by Experts-Exchange (previously ExpertSexChange.com) and Powergen Italia (used to be PowerGenitalia.com)...

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?

[Anonymous Coward]

Being a developer most likely doesn't automatically make you a superuser on their dev servers (I'd hope).

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

Re:Chip and Pin - class joke ..

[Anonymous Coward]

Well, it's syntactically correct, it cannot be "forged" because if you obtained it it would be identical instead of an imitation.

From a provider's point of view, the Chip & PIN approach is indeed one to recommend - after all, if the Credit Card companies get away with surrepticious risk transfer, why not someone else?

In case you didn't get it: since a PIN code is required instead of a signature, it's no longer the bank's duty to check if the signature is correct (i.e. thay should not pay until they have confirmed this). Since PIN, *YOU* WILL HAVE TO PROVE YOU DID /NOT/ ENTER THE PIN - in other words, you have to prove your innocence which is obviously much harder and rather convenient for the Credit Card company and/or bank.

So, if someone fucks up in the security department and unleashes yet another database on the world with all the juicy details (or, as in the proposed use by the original poster which in case of clueless admins would be stored in cleartext instead of a hash) it'll be /your/ problem proving that it wasn't you who authorised payment.

So, now you know why

(a) the Credit Card companies were so incredibly keen on the Chip & PIN idea. Not "for your safety and to prevent fraud" - no, to protect their revenue. That it marginally decreases fraud until you're invited by knifepoint to share your secret PIN is merely incidental. BTW, it also increases your personal risk as it now needs a conversation with you to get that code. A cloned card with a duplicate signature would only take a covert swipe of your details (or the flimsy from the restaurant bin).

(b) using this for web access would be an incredibly dumb idea. Amusing, but dumb ;-).

= Ch =

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.

Two Factor Authentication using Hardtokens!

[Anonymous Coward]

I've really grown to like the pam-usb project. It's very easy to setup, and while I'm no security expert, it seems more secure than just a password/passphrase etc.

Way way Offtopic.....

[supersnail]

Whats going on here. In the "related links" to the left of the article.
I have a couple of links "Compare prices on Linux Software" duh!
Curious as to how they can do a price comparison between free beer "a" and free beer "b"
I clicked the link -- which takes me to a pricegrabber.com site full of adverts for windows PCs.

Why bother! Who is going to by a windows PC when they were looking for cheaper Linux software?

This sort of poorly directed advertising just brings the whole browsing eexperience down a notch in the same way that each spam received makes e-mail that much less useful.

Call me niave but I did expect better of Slashdot. I know the articles can be out of date and/or lame, and, many of the posters (probably including myself) have a warped world view but I always though /. had a pleasingly shambolic integrity.

Oh well I am too old for a MYSPACE account?

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.

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.

why openssh let root to login by default?

[Anonymous Coward]

yes, i agree with you,
i don't understand why SSH on OpenBSD is let root to login by default

GNU/Linux - Windows without the GUI click tools!

[Anonymous Coward]

Linux kernel developers have known for years that their software isn't safe. Why don't they fix it? Seriously, GNU/Linux is not usable as a general purpose shell. Its like Windows. If you can access the system, you can do anything you want.

SDF stopped using GNU/Linux years ago because of this very reason. No software is perfect, but damn!

Check out the SDF com log from when they shutdown the GNU/Linux server. A guy gets root while they are in com. Funny stuff.

ftp://sdf.lonestar.org/pub/sdf/historical/bye-bye- leenox.txt

Re:[OT] poor naming decisions

[Anonymous Coward]

Damn I wish I hadn't used up my mod points yesterday still lmao!!

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

hahaha oh no!

[Intangion]

omg debian's source has been stolen!!
the hacker wouldve had access to the complete source of the distro!! ... oh wait.. so does everyone else..

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.

Slashtard mods in full force.

[Anonymous Coward]

PAM sucks gonads. Adding huge gaping security holes to please idiots who insist on using horrid crap like PAM would be a political decision. Leaving out security holes because security holes are bad is a technical decision. And if any linux people really wanted nicer PAM integration, they could do it themselves. I hope I don't have to explain the concept of open source to you.

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

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.

Strongest password

[Anonymous Coward]

The weak password problem is not that hard to avoid. I have created a program that generates all possible
10 character passwords. Then I let all the password cracking programs I've found on the net try to crack
all these passwords. Of all possible password the hardest one to crack turns out to be "k7HgfS9Db6".
So I always use that password whenever I want be really safe. Everyone should use that one when dealing
with sensitive data.