> Does anyone know if or when Thunderbird will support either an Emacs mode
You do realize, of course, that the source tarball for Emacs is larger than the source tarball for Thunderbird? If what you want is Emacs, it would be easier to add a mailreader to Emacs than to add an Emacs mode to a mailreader. Of course, Emacs already has several mailreaders, the most full-featured and powerful being Gnus (so called because it started its life as a newsreader, way back in the day, before all this new-fangled "world wide web" stuff).
> Emacs bindings were supposed to take precedence
Umm, Emacs lets the user set whatever bindings they want, so I'm not sure what you mean by "the Emacs bindings". Emacs does not have any one set of bindings. It has some defaults, but the defaults are only defaults, and any serious power user will rebind the functions he uses with any frequency to keystrokes that are easy to remember and easy to hit.
Again: if you want Emacs, just use Emacs. Thunderbird will not in the forseeable future begin to approach the functionality of Emacs. (This is not disrespect to Thunderbird, but Emacs has been under development for a very long time by a number of very skilled and dedicated people and so has a huge repertoire of functionality not approached by any other piece of software of which I am aware, with the possible exception of Perl if you count all the modules on CPAN.)
> The way I understand it, all that would do is teach your Bayesian > classifier that HTML tags are slightly junkish
Fundamentally, this isn't going to get you anywhere much. While I get approximately zero legitimate messages in text/html format per annum and roughly fifty illegitimate such messages per day, nevertheless all common HTML tags occur with some frequency in my regular (text/plain) legitimate mail, for one reason or another. (I do some amateur web development and know some people who do it professionally...)
More significantly, text/html spam does not generally have a structure that lends itself very well to bayesian analysis. The "HTML" tends to be custom SGML autogenerated for each message. If you examine some of it closely, you'll see this sort of nonsense:
And so on and so forth. This is designed to abuse the fundamental rule of HTML that unknown tags are ignored. It's also designed to be impossible to write keyword filters for, and it has the side-effect of also being pretty much utterly unfilterable by naive bayesian classification. It is possible to do bayesian filtering in a way that defeats this, but something more than a garden-variety naive application of the technique is required: you have to apply some kind of prefilter before feeding the "words" into your bayes engine. One of the things your prefilter can do is find the word obscured in all that mess. (The prefilter does not have to know that there's anything special or spammy about this word; it just feeds whatever words it finds to Bayes.) The prefilter should also find the same word if some of the letters are encoded in 1337 (e.g., "\/1@GR@"). Again, the prefilter doesn't have to know this word; it only has to know that "\/" is similar to V, "1" in a class alongside "l" and "i" and several other characters, and so on. This is not a great deal more complex than case folding (okay, multibyte characters like/\/\ make it a little more complex, but this is not insurmountable) and will greatly reduce the number of "Vla-gra" advertisements you have to see before the bayesian engine has seen all the several hundred possible variations.
The sort of thing above is also tremendously easy to identify if you have a full-blown scripting language at your fingertips. Just keep a list of all legitimate or common HTML tags and for every distinct "weird" tag you encounter increment the message's weird-tag counter. Messages with more than a certain quota of "weird" tags then get subjected to some additional rules that attempt to determine whether they're some kind of legitimate markup or not, and maybe some rules that expressly look for highly spammy words broken up by the tags as above. (You can take your list of highly spammy words from the stats database that your bayesian engine produces.)
Or like I said, you can prefilter it before you feed it to Bayes, adding the extracted words to the list of tokens.
Stable it may be, but complete it is not. There are still a number of rather vital features that remain to be implemented. This doesn't matter much for people who don't do a lot with email, but for people who are addicted to a lot of poweruser features from mail clients like Pegasus or Gnus, Thunderbird is Not Ready Yet.
Still, it's good to see that progress is being made. The browser is getting to be pretty good, so maybe in a couple of years they'll have a mail client I can think about using. (That would be saying a lot; I'm picky.)
I don't use Thunderbird either (nor Communicator, because they're not featureful enough) but of all the mail options available, hotmail is categorically the absolute worst option, worse even than OE.
I use Gnus, of course. Gnus is nothing if not featureful.
> The cheapest LEGO available is a 2000 piece tub for $20, or 10 cents a piece. > Unfortunately
Your mistake was buying them all new. Lego has been around for quite some time, and so there are a *lot* of them available in secondhand-toy land. When I was a kid, we picked up a big cardboard box of them (must have been two feet long by a foot wide at least, and there were maybe three inches deep of legos in there) at a garage sale for a couple of bucks. Granted, that's an especially good deal, but if you hunt around you should be able to pick up used Legos in good condition at well less than the new price. You'll probably still have to buy some new if you need specialty pieces in certain colours or whatever, but for just plain old ordinary regular-sized bricks that you need in bulk, you should be able to pick up quite a few of them used.
Bear in mind, however, the password it's six thousand times better than is considered in the industry to be reasonably secure. Also bear in mind that my password is so much easier to remember, there's no comparison.
> An attacker would likely initially try at most 5000 common words
(5000^6)/2 is still better than (200^8)/2, but I do tend to prefer somewhat more literate sentences. Something like "Bob shifted paradigms and established a new type of password" is much stronger than "This is my long password". It's ten words long, *much* easier to remember than ten random characters like "Y7bQ(dH|nZ", and includes a couple of words that will not be in the 5000-word dictionary.
This kind of password cannot be generated by software unless you take it from a source of known-good sentences, but that is ill-advised...
> In real life, you'd attack such a password by picking strings from the > fortunes files, books, and other sources of quotes
Passwords should not be chosen from such sources, because if the attacker finds out how you generate your passwords you've just shot your search space all to pieces; therefore, the sysadmin or the users should make these passwords up by hand. Getting users to be creative enough to do so is probably asking too much, but in a world where sysadmins often think nothing of assigning someone a password like "UnG8IxwM", I don't know why they would balk at handing out passwords like "Trying to recall my password makes my mind go all woozy and my brain turn to rice pudding" or "I can remember that green fields of wheat make spectacular password mnemonics" or "George always keeps live salamanders in the office to frighten the cleaning team" or "The pain associated with remembering lengthy passwords is exaggerated."
Yes, all of these include some words that could be put on a short list of "words associated with passwords": recall, remember, password, computer, system, access, and so on, and several forms of all those words. However, you've still got words like "woozy", "rice", "pudding", "fields", "spectacular", "salamanders", "frighten", "associated", and "exaggerated". So the search space is decently large, I assure you. Remember, the goal was not to make the passwords absolutely unbreakable, but only to make them at least as strong as "Be%oPMqR". Also remember that the *real* goal was to make them easier to remember so you can tell the user "Memorize this, because you can't take the slip of paper with you. I have to burn it and grind the ashes to powder. Also, if you're caught telling anyone your password you won't get your bonus at the end of the year and we'll put you on the system where you get a new password to remember every month."
Bonus points of the user also has an ID tag with their photo on it that they have to swipe when they log in, in addition to punching in the memorized password.
> If the cracker knows that your password is a valid English sentence, then > the search space is significantly reduced. For example, you can trivially > discard any combination that doesn't include a verb.
Only if he's doing it by hand. The computer isn't smart enough. Determining part of speech in English is AI-complete. It may not be so in all languages; in particular, it is probably not so in many strongly inflected languages. In a word-order language like English, however, which routinely permits the verbing of nouns and adjectives, determining what does and does not constitute a sentence is famously AI-complete. It would be faster to just try every combination of words.
Re:People can make them whatever they like.
on
Real Security?
·
· Score: 1
> If I were building that system I wouldn't give nurses read/write priviliges
Read privileges alone are enough. Medical record confidentiality and all that.
> I'm assuming that most library admins will have [disabled booting from CD]
I'm a library admin, and on our patron internet stations I've unplugged the data and power cables from all the removable drives (those that *have* removable drives, which is not my preference). Unfortunately, I do have to leave the floppy drives plugged in on the word processing systems, but I do disable booting from them in the BIOS.
If you think these measures aren't necessary, you've never worked in the IT department at a public library.
If I had more control over the budget process, we'd have thin clients.
> Does anyone really follow these rules? How do you remember all your > passwords if you do?
You can only be so paranoid. *Most* of your passwords (e.g., your slashdot password) are generally not worth that kind of trouble. OTOH, a typical user probably has one or two passwords that are, and a sysadmin probably has a dozen. So...
> It should be hard to guess, involving a mix of upper and lower case > letters and numbers, and involving no personal data.
Let's rephrase that: it should be hard to guess and hard to bruteforce. Whether it involves a mix of upper and lower case and numbers is immateriel; that's *one* way to make it hard to brute-force. Sheer length is another way that works even better, without making it so hard to remember.
> It should be different for each site or system.
You should use a unique, secure password for each *important* thing that *needs* to be secure. Your subscription to a given blog, online newspaper, or whatnot is not in this category.
I use an insecure password for my Amazon account -- I can do that, because I have not given Amazon any data that needs to be secure (for example, I have not given them any credit card numbers; I prefer to pay by check). If someone guesses or brute-forces my password, they can order something in my name. If they *pay* for it, it'll even get delivered. Whoopee. They could do all of that anyway by creating a new account with my name (using, say, a free hotmail account for the email) and information out of a phonebook.
OTOH, the root password for my MySQL database at work is sixteen characters long, including both cases and numbers -- and yes, I have it memorized.
> You should change it often.
Depends. Passwords you don't use very often don't need to be changed very often. You should change your password any time you believe there is a chance it may have been compromised (e.g., if someone stands over your shoulder while you enter it), and really critical passwords should also be rotated from time to time, yeah.
> You shouldn't write it down or put it in a text file.
Absolutely don't put it in a text file.
Don't write it down? Depends. How's the security of your building? Also, are you primarily concerned about someone with physical access, or remote attacks? There are some passwords that I do write down, because losing them is more likely to be a problem than an attack by a person with physical access. Now, that said, by "write down" I absolutely do not mean "adhere to the monitor on a sticky note" in a public office. Passwords you write down should still put where getting/finding them is at least as hard as removing the hard drive and mounting it in another system.
> Does anyone really follow these rules?
They're guidelines. You also have to use that squishy grey thing between your ears.
Re:People can make them whatever they like.
on
Real Security?
·
· Score: 1
> requiring passwords to be so odd isn't really protecting anything, as > users will voluntarily do so if it is anything they care about
There are some situations where the user may not care, but the sysadmin has to protect the security of the system anyway. Hospitals are an excellent example. Approximately zero percent of nurses understand why passwords on hospital systems should be secure, and they will happily use their birthdates if permitted to do so. Legally, the hospital absolutely cannot allow that.
Re:Two minds about it
on
Real Security?
·
· Score: 5, Informative
> thisismylongasspassword
That's better than you think. My/usr/share/dict/words has over 45000 words in it, which is probably typical. The above password is six words long (which if anything is pretty short, as sentences go). That means you can brute force it in about (45000^6)/2 tries, on average. Compare that to a typical "strong" eight-character password (e.g., "bVi-Q*cY"), which can be brute forced in (N^8)/2 tries, on average, where N is about 100 or 200 or so, depending on your character set. The sentence starts looking pretty good -- and it's a *lot* easier to remember.
> thi!$1smyp4$s
Yes, increasing the length to over 12 characters greatly improves the security of a traditional ugly password. (N^13)/2 is about N^5 times better than (N^8)/2, so with an N of around 80 characters (upper and lower case letters, digits, and about 20 common printable punctuation marks) that's about a three-billion-fold improvement in the time needed to brute-force it.
I personally tend to favour a combination of these approaches. Take your sentence (say, "I tend to favour a combination of these approaches.", make a handful of key substitutions, and you get a password like this: I-t3nd-2-PHavour-a-c0mbinat|on-0f-these-app roacheZ
The sentence is easy to remember. In addition to the sentence, you have in the above example seven substitutions. That's a total of eight things to remember, barely (if at all) harder than tB8k^yQp and pretty much impossible to brute force. (If you do the arithmetic on this sucker, it's impressive. Even assuming a clever modified dictionary attack, the sentence is nine words long (nine *words*, not nine chars), and furthermore there are several possible ways to mangle each word. The mere electricity your CPUs would use up running the possibilities boggles the mind; whatever the password is protecting, you could buy it cheaper.) Then you have to worry about things like sniffers, surveillance, and rubber hose cryptanalysis, if the password unlocks something worth anyone's trouble to bother with all that.
Send her here. Really. I taught
myself HTML in my spare moments during a weekend using a much worse tutorial
than that, and I was in college at the time. Kids learn faster. In three
hours she'll have the HTML figured out and be looking for clip-art.
> Or, pick a minimal install, then use something like urpmi or apt-get or > yum to install just the software you want.
That would take forever. You'd be days tracking down all the things you want and getting them installed. At that point you might just as well use Gentoo.
> * back out easily. 'rpm -e' or 'pkgrm' are easier than grepping through > the Makefiles for all of the installed programs and piping that to > 'find / -name $1 -exec rm' or whatever. > * copy the package to other servers and install quickly and easily. This > allows you create once, install anywhere, and you can even script the > installation process.
You should look into checkinstall, if you haven't already. Basically, checkinstall replaces the make install portion of the above procedure and builds a package (RPM being one of three package-type options).
> * avoid overwriting existing files. Any decent package manager will complain > if the target file(s) already exists.
Except in/etc I've never found this to be a problem, unless you are trying to have multiple versions of the same package installed, in which case you really need to use the prefix option for the configure script anyway. As far as/etc, you really should have it mirrored in another directory anyway.
(Actually, I like some things about the way Gentoo handles/etc, though it could use some tweaking yet. e.g., for any given/etc/foo there ought to be/etc/foo.orig which you don't edit, so that your edits could be extracted as a diff; in many cases the new version could be automatically patched with your edits; you'd only have to merge them manually if you made changes in some of the same places where the file changed from the old version to the new one. The (unpatched) new version would then become the new foo.orig.)
> It's kind of a stretch that they are calling this a Certified Linux Engineer
I thought it was Novell Certified Linux Engineer. Now, I suppose you could read that as Novell-Certified Linux Engineer (i.e., a Linux Engineer who is Certified by Novell), but without the hyphen the natural reading IMO is that Novell and Certified and Linux are all adjectives modifying the noun Engineer. i.e., this certification is not about Linux per se but rather the combination of Novell and Linux (or, more particularly, Novell running on Linux). Seems reasonable to me. There are other certs out there if you just want to be certified to work with Linux systems in general. This is a Novell certification, so of course it relates to Novell systems.
> Ah, the endless loop. When employed, certs are not needed
I would think that if you've been employed for a decent amount of time in a relevant job, you wouldn't need the certs afterward either, unless you're fired for incompetence or something. Last I checked, job experience was worth a good deal more than certs. (A degree is nice to have too...)
Well, there's lazy and then there's lazy. Some people are lazy enough to put out the effort needed to learn how to set things up properly so that they run themselves and we can kick back a bit. This is the virtue of laziness.
If you're too lazy to learn the proper skills to make things work that way, so that you are constantly troubleshooting preventable problems that crop up because of flaws in your setup, that is False Laziness.
If you read the camel book, you will also learn about the distinction between the virtues of Impatience and Hubris and their corresponding antitheses, False Impatience and False Hubris.
> I believe the current "best practice" is to wait at least 1 week for the > vendor to initially respond... and to give them at least 1 month to create > a patch if they (privately) acknowledge the problem.
Ordinarily I would agree with this for most products (even most Microsoft products -- e.g., if you find a security flaw in their CIFS implementation or something), but MSIE's security track record is so horrifically aweful that any attempt to follow these practices in the case of MSIE is a total waste of time. Microsoft has proven repeatedly that they do not consider a reported security flaw in MSIE (or MSOE) to be worth their time until it is actively exploited by the blackhat community. My guess is that this is a result of internal policy within the MSIE team itself, more than Microsoft in general. Vulnerabilities in many of their other components get patches before the exploit hits the wild, so we have to assume that whoever answers the mail does forward it along to the appropriate team. But when the MSIE team gets them, they apparently file them in the bit bucket until something disastrous happens to bring it to their attention for real.
IMO, since there's a workaround (disable Active Scripting), the researcher was right to make this public, so that people can protect themselves *before* the exploit hits. There was essentially no hope that the patch would come out in time for that, regardless of any best practices followed.
> They could have just distributed IE with Windows and have it install by > default. Sure users would be able to uninstall it, but how many home users > would even bother to uninstall it and install their browser of choice as > long as IE wasn't a total piece of crap?
You seem to be forgetting that versions of IE prior to 5.5 or so *were* total crap, and I don't mean just in terms of security. IE4 was worse than Netscape Communicator 4, which almost all of us now consider totally unusable. IE didn't actually get to be halfway decent until *after* it already had a very strong market share (due to bundling). For example, such basic features as Print Preview were added *after* the release of 5.0 and didn't always work right at first.
The fact that security is now universally considered one of the biggest shortcomings of IE, whereas before it wasn't, is not because the security somehow suddenly got worse; it's because MSIE is in many respects now quite good. Three years ago it was junk in pretty much every respect; Microsoft has actually made huge progress with IE. They probably now need to rebuild it mostly from scratch to stop the perpetual security issues, but they now have some leisure to do that, since apart from a couple of minor things (e.g. popup blocking) there are few urgent feature needs in the extant codebase. They ought to be able to build a fresh browser from the ground up now and bring it out in about three years with fanfare and hype as the best thing since sliced bread (i.e., IE).
What they're going to do about Outlook, I don't know. If they want to shake their reputation for bad security, they've got to do *something* about Outlook, obviously.
> I am amazed that the US continues to tolerate their system, or maybe > poorer people don't vote.
Warning: generalisations follow...
Actually, our system in the US as it stands now *greatly* favours the non-working poor. Hugely so. Normal people put things off for weeks and months because the 40% we have to pay after the insurance company pays its share is still quite a lot of money; people on Medicare, meanwhile, call routinely an ambulance for non-emergency things just because they can't be bothered to get someone to drive them a quarter mile to the hospital. It doesn't cost them anything. They abuse the emergency room, too, going in for the most flagrant of non-emergencies because (unlike a doctor's office visit) it costs them nothing.
I don't mind a certain amount of paying for poor people to have some health care, but it has frankly gotten entirely out of hand. The percentage of my
paycheck going for other people's health care needs is a good deal higher than what I pay for health care for myself, including dental checkups and everything. (Granted, I'm single, but still...) I say, make 'em pay 40% like the rest of us, *especially* for non-critical stuff, like calling an ambulence for a condition that hadn't changed in hours.
Oh, and if I had my way smoking would disqualify you from receiving any help at all; if you don't have any concern for your own health, how can you expect the rest of us to take the responsibility that you won't? This is a harsh, narrow-minded, and unpopular view, but I didn't come to it out of randomness or meanness.
Slashdot Mirror
> Does anyone know if or when Thunderbird will support either an Emacs mode
You do realize, of course, that the source tarball for Emacs is larger than
the source tarball for Thunderbird? If what you want is Emacs, it would be
easier to add a mailreader to Emacs than to add an Emacs mode to a mailreader.
Of course, Emacs already has several mailreaders, the most full-featured and
powerful being Gnus (so called because it started its life as a newsreader,
way back in the day, before all this new-fangled "world wide web" stuff).
> Emacs bindings were supposed to take precedence
Umm, Emacs lets the user set whatever bindings they want, so I'm not sure
what you mean by "the Emacs bindings". Emacs does not have any one set of
bindings. It has some defaults, but the defaults are only defaults, and any
serious power user will rebind the functions he uses with any frequency to
keystrokes that are easy to remember and easy to hit.
Again: if you want Emacs, just use Emacs. Thunderbird will not in the
forseeable future begin to approach the functionality of Emacs. (This is not
disrespect to Thunderbird, but Emacs has been under development for a very
long time by a number of very skilled and dedicated people and so has a huge
repertoire of functionality not approached by any other piece of software of
which I am aware, with the possible exception of Perl if you count all the
modules on CPAN.)
Sounds like a job for WWW::Mechanize.
> The way I understand it, all that would do is teach your Bayesian
a <i wqeerqytrxa>g<pomzbelfsk>r <ilenvpwjngie>a</b>
/\/\ make it a little more complex, but this is not insurmountable) and will
> classifier that HTML tags are slightly junkish
Fundamentally, this isn't going to get you anywhere much. While I get
approximately zero legitimate messages in text/html format per annum and
roughly fifty illegitimate such messages per day, nevertheless all common
HTML tags occur with some frequency in my regular (text/plain) legitimate
mail, for one reason or another. (I do some amateur web development and
know some people who do it professionally...)
More significantly, text/html spam does not generally have a structure that
lends itself very well to bayesian analysis. The "HTML" tends to be custom
SGML autogenerated for each message. If you examine some of it closely, you'll
see this sort of nonsense:
<b><gcaelielaen>V<roiqwnbmlz>i<oqiwjhxoisdoifd>
And so on and so forth. This is designed to abuse the fundamental rule of
HTML that unknown tags are ignored. It's also designed to be impossible to
write keyword filters for, and it has the side-effect of also being pretty
much utterly unfilterable by naive bayesian classification. It is possible
to do bayesian filtering in a way that defeats this, but something more than
a garden-variety naive application of the technique is required: you have
to apply some kind of prefilter before feeding the "words" into your bayes
engine. One of the things your prefilter can do is find the word obscured
in all that mess. (The prefilter does not have to know that there's anything
special or spammy about this word; it just feeds whatever words it finds to
Bayes.) The prefilter should also find the same word if some of the letters
are encoded in 1337 (e.g., "\/1@GR@"). Again, the prefilter doesn't have to
know this word; it only has to know that "\/" is similar to V, "1" in a class
alongside "l" and "i" and several other characters, and so on. This is not
a great deal more complex than case folding (okay, multibyte characters like
greatly reduce the number of "Vla-gra" advertisements you have to see before
the bayesian engine has seen all the several hundred possible variations.
The sort of thing above is also tremendously easy to identify if you have a
full-blown scripting language at your fingertips. Just keep a list of all
legitimate or common HTML tags and for every distinct "weird" tag you
encounter increment the message's weird-tag counter. Messages with more
than a certain quota of "weird" tags then get subjected to some additional
rules that attempt to determine whether they're some kind of legitimate
markup or not, and maybe some rules that expressly look for highly spammy
words broken up by the tags as above. (You can take your list of highly
spammy words from the stats database that your bayesian engine produces.)
Or like I said, you can prefilter it before you feed it to Bayes, adding
the extracted words to the list of tokens.
Stable it may be, but complete it is not. There are still a number of rather
vital features that remain to be implemented. This doesn't matter much for
people who don't do a lot with email, but for people who are addicted to a lot
of poweruser features from mail clients like Pegasus or Gnus, Thunderbird is
Not Ready Yet.
Still, it's good to see that progress is being made. The browser is getting
to be pretty good, so maybe in a couple of years they'll have a mail client
I can think about using. (That would be saying a lot; I'm picky.)
I don't use Thunderbird either (nor Communicator, because they're not featureful
enough) but of all the mail options available, hotmail is categorically the
absolute worst option, worse even than OE.
I use Gnus, of course. Gnus is nothing if not featureful.
> The cheapest LEGO available is a 2000 piece tub for $20, or 10 cents a piece.
> Unfortunately
Your mistake was buying them all new. Lego has been around for quite some time,
and so there are a *lot* of them available in secondhand-toy land. When I was
a kid, we picked up a big cardboard box of them (must have been two feet long
by a foot wide at least, and there were maybe three inches deep of legos in
there) at a garage sale for a couple of bucks. Granted, that's an especially
good deal, but if you hunt around you should be able to pick up used Legos in
good condition at well less than the new price. You'll probably still have to
buy some new if you need specialty pieces in certain colours or whatever, but
for just plain old ordinary regular-sized bricks that you need in bulk, you
should be able to pick up quite a few of them used.
> By the way, what's "AI-complete"? Do you mean "NP complete"?
No, I do not mean NP complete. Do a google search for AI complete, or check
the jargon file or Wikipedia.
> It's only about six thousand times better
Bear in mind, however, the password it's six thousand times better than is
considered in the industry to be reasonably secure. Also bear in mind that
my password is so much easier to remember, there's no comparison.
> An attacker would likely initially try at most 5000 common words
(5000^6)/2 is still better than (200^8)/2, but I do tend to prefer somewhat
more literate sentences. Something like "Bob shifted paradigms and established
a new type of password" is much stronger than "This is my long password". It's
ten words long, *much* easier to remember than ten random characters like
"Y7bQ(dH|nZ", and includes a couple of words that will not be in the 5000-word
dictionary.
This kind of password cannot be generated by software unless you take it from
a source of known-good sentences, but that is ill-advised...
> In real life, you'd attack such a password by picking strings from the
> fortunes files, books, and other sources of quotes
Passwords should not be chosen from such sources, because if the attacker
finds out how you generate your passwords you've just shot your search space
all to pieces; therefore, the sysadmin or the users should make these
passwords up by hand. Getting users to be creative enough to do so is
probably asking too much, but in a world where sysadmins often think nothing
of assigning someone a password like "UnG8IxwM", I don't know why they would
balk at handing out passwords like "Trying to recall my password makes my
mind go all woozy and my brain turn to rice pudding" or "I can remember that
green fields of wheat make spectacular password mnemonics" or "George always
keeps live salamanders in the office to frighten the cleaning team" or "The
pain associated with remembering lengthy passwords is exaggerated."
Yes, all of these include some words that could be put on a short list of
"words associated with passwords": recall, remember, password, computer,
system, access, and so on, and several forms of all those words. However,
you've still got words like "woozy", "rice", "pudding", "fields",
"spectacular", "salamanders", "frighten", "associated", and "exaggerated".
So the search space is decently large, I assure you. Remember, the goal
was not to make the passwords absolutely unbreakable, but only to make them
at least as strong as "Be%oPMqR". Also remember that the *real* goal was to
make them easier to remember so you can tell the user "Memorize this, because
you can't take the slip of paper with you. I have to burn it and grind the
ashes to powder. Also, if you're caught telling anyone your password you
won't get your bonus at the end of the year and we'll put you on the system
where you get a new password to remember every month."
Bonus points of the user also has an ID tag with their photo on it that they
have to swipe when they log in, in addition to punching in the memorized
password.
> If the cracker knows that your password is a valid English sentence, then
> the search space is significantly reduced. For example, you can trivially
> discard any combination that doesn't include a verb.
Only if he's doing it by hand. The computer isn't smart enough. Determining
part of speech in English is AI-complete. It may not be so in all languages;
in particular, it is probably not so in many strongly inflected languages.
In a word-order language like English, however, which routinely permits the
verbing of nouns and adjectives, determining what does and does not constitute
a sentence is famously AI-complete. It would be faster to just try every
combination of words.
> If I were building that system I wouldn't give nurses read/write priviliges
Read privileges alone are enough. Medical record confidentiality and all that.
> I'm assuming that most library admins will have [disabled booting from CD]
I'm a library admin, and on our patron internet stations I've unplugged the
data and power cables from all the removable drives (those that *have*
removable drives, which is not my preference). Unfortunately, I do have to
leave the floppy drives plugged in on the word processing systems, but I do
disable booting from them in the BIOS.
If you think these measures aren't necessary, you've never worked in the IT
department at a public library.
If I had more control over the budget process, we'd have thin clients.
> Does anyone really follow these rules? How do you remember all your
> passwords if you do?
You can only be so paranoid. *Most* of your passwords (e.g., your slashdot
password) are generally not worth that kind of trouble. OTOH, a typical
user probably has one or two passwords that are, and a sysadmin probably
has a dozen. So...
> It should be hard to guess, involving a mix of upper and lower case
> letters and numbers, and involving no personal data.
Let's rephrase that: it should be hard to guess and hard to bruteforce.
Whether it involves a mix of upper and lower case and numbers is immateriel;
that's *one* way to make it hard to brute-force. Sheer length is another way
that works even better, without making it so hard to remember.
> It should be different for each site or system.
You should use a unique, secure password for each *important* thing that
*needs* to be secure. Your subscription to a given blog, online newspaper,
or whatnot is not in this category.
I use an insecure password for my Amazon account -- I can do that, because I
have not given Amazon any data that needs to be secure (for example, I have
not given them any credit card numbers; I prefer to pay by check). If
someone guesses or brute-forces my password, they can order something in my
name. If they *pay* for it, it'll even get delivered. Whoopee. They could
do all of that anyway by creating a new account with my name (using, say, a
free hotmail account for the email) and information out of a phonebook.
OTOH, the root password for my MySQL database at work is sixteen characters
long, including both cases and numbers -- and yes, I have it memorized.
> You should change it often.
Depends. Passwords you don't use very often don't need to be changed
very often. You should change your password any time you believe there
is a chance it may have been compromised (e.g., if someone stands over
your shoulder while you enter it), and really critical passwords should
also be rotated from time to time, yeah.
> You shouldn't write it down or put it in a text file.
Absolutely don't put it in a text file.
Don't write it down? Depends. How's the security of your building? Also,
are you primarily concerned about someone with physical access, or remote
attacks? There are some passwords that I do write down, because losing them
is more likely to be a problem than an attack by a person with physical
access. Now, that said, by "write down" I absolutely do not mean "adhere
to the monitor on a sticky note" in a public office. Passwords you write
down should still put where getting/finding them is at least as hard as
removing the hard drive and mounting it in another system.
> Does anyone really follow these rules?
They're guidelines. You also have to use that squishy grey thing between
your ears.
> requiring passwords to be so odd isn't really protecting anything, as
> users will voluntarily do so if it is anything they care about
There are some situations where the user may not care, but the sysadmin has
to protect the security of the system anyway. Hospitals are an excellent
example. Approximately zero percent of nurses understand why passwords on
hospital systems should be secure, and they will happily use their birthdates
if permitted to do so. Legally, the hospital absolutely cannot allow that.
> thisismylongasspassword
/usr/share/dict/words has over 45000 words
p roacheZ
That's better than you think. My
in it, which is probably typical. The above password is six words long (which
if anything is pretty short, as sentences go). That means you can brute force
it in about (45000^6)/2 tries, on average. Compare that to a typical "strong"
eight-character password (e.g., "bVi-Q*cY"), which can be brute forced in
(N^8)/2 tries, on average, where N is about 100 or 200 or so, depending on
your character set. The sentence starts looking pretty good -- and it's a
*lot* easier to remember.
> thi!$1smyp4$s
Yes, increasing the length to over 12 characters greatly improves the security
of a traditional ugly password. (N^13)/2 is about N^5 times better than
(N^8)/2, so with an N of around 80 characters (upper and lower case letters,
digits, and about 20 common printable punctuation marks) that's about a
three-billion-fold improvement in the time needed to brute-force it.
I personally tend to favour a combination of these approaches. Take your
sentence (say, "I tend to favour a combination of these approaches.", make
a handful of key substitutions, and you get a password like this:
I-t3nd-2-PHavour-a-c0mbinat|on-0f-these-ap
The sentence is easy to remember. In addition to the sentence, you have in
the above example seven substitutions. That's a total of eight things to
remember, barely (if at all) harder than tB8k^yQp and pretty much impossible
to brute force. (If you do the arithmetic on this sucker, it's impressive.
Even assuming a clever modified dictionary attack, the sentence is nine
words long (nine *words*, not nine chars), and furthermore there are
several possible ways to mangle each word. The mere electricity your CPUs
would use up running the possibilities boggles the mind; whatever the
password is protecting, you could buy it cheaper.) Then you have to worry
about things like sniffers, surveillance, and rubber hose cryptanalysis, if
the password unlocks something worth anyone's trouble to bother with all that.
> Come on, who uses passwords like '%33#Gt(;' nowadays
Are you kidding? That's too short by half.
Send her here. Really. I taught myself HTML in my spare moments during a weekend using a much worse tutorial than that, and I was in college at the time. Kids learn faster. In three hours she'll have the HTML figured out and be looking for clip-art.
> Or, pick a minimal install, then use something like urpmi or apt-get or
> yum to install just the software you want.
That would take forever. You'd be days tracking down all the things you want
and getting them installed. At that point you might just as well use Gentoo.
> * back out easily. 'rpm -e' or 'pkgrm' are easier than grepping through
/etc I've never found this to be a problem, unless you are trying /etc, you really should have it mirrored in another directory anyway.
/etc, though it /etc/foo there ought to be /etc/foo.orig which you don't edit, so that your edits could be extracted as .)
> the Makefiles for all of the installed programs and piping that to
> 'find / -name $1 -exec rm' or whatever.
> * copy the package to other servers and install quickly and easily. This
> allows you create once, install anywhere, and you can even script the
> installation process.
You should look into checkinstall, if you haven't already. Basically,
checkinstall replaces the make install portion of the above procedure
and builds a package (RPM being one of three package-type options).
> * avoid overwriting existing files. Any decent package manager will complain
> if the target file(s) already exists.
Except in
to have multiple versions of the same package installed, in which case you
really need to use the prefix option for the configure script anyway. As far
as
(Actually, I like some things about the way Gentoo handles
could use some tweaking yet. e.g., for any given
a diff; in many cases the new version could be automatically patched with
your edits; you'd only have to merge them manually if you made changes in
some of the same places where the file changed from the old version to the
new one. The (unpatched) new version would then become the new foo.orig
> It's kind of a stretch that they are calling this a Certified Linux Engineer
I thought it was Novell Certified Linux Engineer. Now, I suppose you could
read that as Novell-Certified Linux Engineer (i.e., a Linux Engineer who
is Certified by Novell), but without the hyphen the natural reading IMO is
that Novell and Certified and Linux are all adjectives modifying the noun
Engineer. i.e., this certification is not about Linux per se but rather the
combination of Novell and Linux (or, more particularly, Novell running on
Linux). Seems reasonable to me. There are other certs out there if you just
want to be certified to work with Linux systems in general. This is a Novell
certification, so of course it relates to Novell systems.
> Ah, the endless loop. When employed, certs are not needed
I would think that if you've been employed for a decent amount of time in
a relevant job, you wouldn't need the certs afterward either, unless you're
fired for incompetence or something. Last I checked, job experience was
worth a good deal more than certs. (A degree is nice to have too...)
> Are they saying that we are lazy?
Well, there's lazy and then there's lazy. Some people are lazy enough to
put out the effort needed to learn how to set things up properly so that
they run themselves and we can kick back a bit. This is the virtue of
laziness.
If you're too lazy to learn the proper skills to make things work that way,
so that you are constantly troubleshooting preventable problems that crop up
because of flaws in your setup, that is False Laziness.
If you read the camel book, you will also learn about the distinction between
the virtues of Impatience and Hubris and their corresponding antitheses, False
Impatience and False Hubris.
> I believe the current "best practice" is to wait at least 1 week for the
> vendor to initially respond... and to give them at least 1 month to create
> a patch if they (privately) acknowledge the problem.
Ordinarily I would agree with this for most products (even most Microsoft
products -- e.g., if you find a security flaw in their CIFS implementation
or something), but MSIE's security track record is so horrifically aweful
that any attempt to follow these practices in the case of MSIE is a total
waste of time. Microsoft has proven repeatedly that they do not consider a
reported security flaw in MSIE (or MSOE) to be worth their time until it is
actively exploited by the blackhat community. My guess is that this is a
result of internal policy within the MSIE team itself, more than Microsoft
in general. Vulnerabilities in many of their other components get patches
before the exploit hits the wild, so we have to assume that whoever answers
the mail does forward it along to the appropriate team. But when the MSIE
team gets them, they apparently file them in the bit bucket until something
disastrous happens to bring it to their attention for real.
IMO, since there's a workaround (disable Active Scripting), the researcher was
right to make this public, so that people can protect themselves *before* the
exploit hits. There was essentially no hope that the patch would come out in
time for that, regardless of any best practices followed.
> They could have just distributed IE with Windows and have it install by
> default. Sure users would be able to uninstall it, but how many home users
> would even bother to uninstall it and install their browser of choice as
> long as IE wasn't a total piece of crap?
You seem to be forgetting that versions of IE prior to 5.5 or so *were* total
crap, and I don't mean just in terms of security. IE4 was worse than Netscape
Communicator 4, which almost all of us now consider totally unusable. IE
didn't actually get to be halfway decent until *after* it already had a very
strong market share (due to bundling). For example, such basic features as
Print Preview were added *after* the release of 5.0 and didn't always work
right at first.
The fact that security is now universally considered one of the biggest
shortcomings of IE, whereas before it wasn't, is not because the security
somehow suddenly got worse; it's because MSIE is in many respects now quite
good. Three years ago it was junk in pretty much every respect; Microsoft
has actually made huge progress with IE. They probably now need to rebuild
it mostly from scratch to stop the perpetual security issues, but they now
have some leisure to do that, since apart from a couple of minor things
(e.g. popup blocking) there are few urgent feature needs in the extant
codebase. They ought to be able to build a fresh browser from the ground
up now and bring it out in about three years with fanfare and hype as the
best thing since sliced bread (i.e., IE).
What they're going to do about Outlook, I don't know. If they want to
shake their reputation for bad security, they've got to do *something*
about Outlook, obviously.
> I am amazed that the US continues to tolerate their system, or maybe
> poorer people don't vote.
Warning: generalisations follow...
Actually, our system in the US as it stands now *greatly* favours the
non-working poor. Hugely so. Normal people put things off for weeks and
months because the 40% we have to pay after the insurance company pays its
share is still quite a lot of money; people on Medicare, meanwhile, call
routinely an ambulance for non-emergency things just because they can't be
bothered to get someone to drive them a quarter mile to the hospital. It
doesn't cost them anything. They abuse the emergency room, too, going in
for the most flagrant of non-emergencies because (unlike a doctor's office
visit) it costs them nothing.
I don't mind a certain amount of paying for poor people to have some health
care, but it has frankly gotten entirely out of hand. The percentage of my
paycheck going for other people's health care needs is a good deal higher
than what I pay for health care for myself, including dental checkups and
everything. (Granted, I'm single, but still...) I say, make 'em pay 40%
like the rest of us, *especially* for non-critical stuff, like calling an
ambulence for a condition that hadn't changed in hours.
Oh, and if I had my way smoking would disqualify you from receiving any help
at all; if you don't have any concern for your own health, how can you expect
the rest of us to take the responsibility that you won't? This is a harsh,
narrow-minded, and unpopular view, but I didn't come to it out of randomness
or meanness.