> In fairness, the Advanced Bash Scripting Guide here is a great resource > for people wanting a good reference to bash scripting and shell scripting > in general.
The documentation for bash is good, but the previous poster was talking about plain vanilla traditional back-in-the-day-style bourne shell scripting, the kind where you don't use any bash-specific features or other non-portable stuff. bash is fine if you only have to support Linux systems, cygwin, and the modern BSDs maybe, but it's not ubiquitous enough to achieve the kind of real portability (among *nix systems) that people use plain vanilla bourne shell scripting for.
Perl is *significantly* more widely ubiquitous than bash (to the extent that it's pretty unusual to find a system with bash and no perl, but the reverse is not at all unusual), and if you count non-*nix systems it's probably these days more widely deployed even than sh. So in terms of portability, writing core Perl that doesn't require anything more recent than 5.003 is actually a pretty good option.
Of course if you want *real* portability you write in Inform and compile to the z-machine, preferably version 3... [mutters something incoherent about Perl not running on TRS80 or Nintendo Gameboy]
> I always thought, liberal or conservative, it made more sense to AUTOMATE > the federal tax by eliminating the paperwork and going to a sales tax model > (excepting food and medicine of course), and if the overhead was 5-10% > instead of 40% that's quite an improvement.
The liberals would never go for that, for several reasons. First, a smaller IRS means fewer people on government payroll. Second, you're effectively charging everyone the same tax rate and, importantly, this is obvious. Income tax allows you to charge higher-income people more tax, and that has always been an important feature of the liberal viewpoint on taxes. Third, everyone would see how much they're paying every single time they buy anything. Currently you see part of the picture when you buy something, part of the picture when you look at your paycheck stub, et cetera. It's all broken up, so you don't realize how much of your money you're giving up.
Personally, I'd vote for a system of sales and excise taxes in a heartbeat, but they're not asking me.
> Why do trains in the wide open midwest not make sense?
Because the standard deviation of population density is too low. There are relatively few really large cities, quite a few medium-sized cities, and a hillion jillion quadrillion small cities. The small cities collectively contain most of the population. The number of possible points of origin and destination for a trip, then, are too large compared to the number of trips taken.
Sure, there are lines that would be worth running, such as from Mansfield to Columbus, Mansfield to Cleveland, Cleveland to Toledo, Toledo to Chicago, Cleveland to Youngstown, Youngstown to Buffalo, Youngstown to Pittsburgh, Columbus to Cincinatti, Cincinatti to Indianapolis, and so on -- but these comprise a rediculously small percentage of the trips people take by car; putting in all of the mentioned lines would have very little impact on the number of miles driven by car in Ohio.
Yes, but *not* on the production systems! Install Gentoo on a workstation or a spare system or something, for the learning experience, but keep the production systems on a less bleeding-edge distribution. Seriously. I like Gentoo, but it tends to pick up quite new versions of things before they've been hammered on for very long.
> Next step (and here's where I actually get into answering your question): > Learn (bourne) shell scripting.
I have a different suggestion here. If you were going to be administering a bunch of older, proprietary Unix systems, this would be sound advice, for sure. However, the OP seems to indicate that everything in question is at least somewhat close to modern and open to the concept of upgrades. In that kind of environment, you're not likely to run into a crochety old SunOS box that can't be upgraded to Solaris because of application compatibility and doesn't have space on the disk for an upgrade of Perl to version 5. What you are likely to have is Perl 5.005 or later (*probably* 5.6 or later) on every single system. Given that, shell scripting starts to look like a quite lousy option. The documentation is poor and poorly organized, since it's scattered across myriad utilities (awk, sed, and so on and so forth), each of which has a handful of mostly-standard options and a whole bunch of extended options that vary just a bit from distribution to distribution. You can't use the man pages for reference, because you'll end up doing something that breaks when you try to run it on BSD. There are books on portable shell scripting, but Perl is much more consistent and the books are better. If you already know shell scripting, that's fine, but if you don't, and if you don't have to work with antequated systems, learning it now is probably a waste of time, mostly, time that you could be spending learning something else. Get a copy of the camel book and be happy.
# One last improvement -- actually go to a result page: print "Google "; {
use WWW::Mechanize; use HTML::TreeBuilder;
open WORDS, "</usr/share/dict/words";
my @w = map { chomp; $_ } <WORDS>; close WORDS;
($a, $b, my $phrase) = map {$w[rand@w]} 1..2;
print "$a $b | mung2: \t";
while (not $phrase) {
my $browser = WWW::Mechanize->new();
$browser->get("http://www.google.com/search?hl=en& ie=UTF-8&oe=UTF-8&q=$a+$b&btnG=Google+Search");
$browser->follow_link(n => 10); # Tenth link is first result (currently).
my $content = $browser->content(); my $t = HTML::TreeBuilder->new()->parse($content);
my @s = grep { length $_ > 25 and length $_ < 200 and not/\d+k/i }
split/[^A-Za-z0-9, -]/, $t->as_text();
my @token = split/\s+/, $s[rand@s];
$phrase = ucfirst lc join "_", grep { not/^\s*$/ } map { s/\W//g; $_ } @token;
}
print "$phrase\n"; }
> Personally, I was working on a program for generation of passwords from > fortune, so that things are handled consistently, but I've stalled the > idea until I get get it to use a significantly larger basis for the > mnemonics (as if you knew the source of the mnemonics, and the rules for > generating passwords, it's just as easy to brute force as a dictionary > attack)
Idea: Take two random words from/usr/share/dict/words, Google for them, yank a phrase out of the result, and mung it according to your rules...
#!/usr/bin/perl
print "VCVCVC: \t"; {
sub v { my @v = qw (a e i o u); $v[rand@v]; }
sub c {my@c=split//,'bcdefghjklmnpqrstvwxyz'; $c[rand@c]}
print((map {c() . v()} 1..4), c(), $/); }
print "word-word-word: \t"; {
open WORDS, "</usr/share/dict/words";
my @w = map { chomp; $_ } <WORDS>; close WORDS;
print join '-', map {$w[rand@w]}1..4; print "\n"; }
print "Google word word | mung: \t"; {
open WORDS, "</usr/share/dict/words";
my @w = map { chomp; $_ } <WORDS>; close WORDS;
($a, $b) = map {$w[rand@w]} 1..2;
use WWW::Mechanize; use HTML::TreeBuilder;
my $browser = WWW::Mechanize->new();
$browser->get("http://www.google.com/search?hl=en& ie=UTF-8&oe=UTF-8&q=$a+$b&btnG=Google+Search");
my $content = $browser->content(); my $t = HTML::TreeBuilder->new()->parse($content);
$_ = $t->as_text(); s/\W//g; my @token = split/\s+/, lc $_;
my $idx = rand(@token) - 7; my $phrase = join "_", @token[$idx+1..($idx+6)];
print "$phrase\n";
# use Data::Dumper; print Dumper(\@token) . $/; } # Results: # edu_campus_hook_the_official_college # nationalist_community_the_khazar_theory_by # seemed_to_make_jirov_angry_and # 3_he_rested_from_all_the
This was very quick. You could do your phrase-choosing and munging differently.
Dunno. The only foreign language I know much of is Common Greek, and this technique is somewhat less useful with Common Greek than Korean, since many Common Greek words have a fairly direct English cognate. For example, "Many Common Greek words have" comes out as something like "polus logoi Koine echo"; the first word "polus" (much/many) AFAIK does not have a cognate, but the next two do, and "echo" is a false cognate, I think. (The english word "echo" does come from a Greek word, but it's a different and probably unrelated word.) You see the problem. It doesn't look directly like English words, but if the password rules are looking for English roots with the endings mangled to reject stuff like "basket47", they're going to alarm on "logoi" for sure and *possibly* "Koine" as well (depending on how loose the matching is), and of course "echo" won't go through if there's any checking at all.
> For example, I have to supply uid/pwd in order to read the Washington Post > (my local newspaper). Is it important to keep this password secret?
No, but it's not important to the Washington Post that you keep it secret, either. If someone steals the password, they could (gasp) read the paper.
An important trick in the security toolbag is to give users the priveleges they actually need and no more. Let's say you're an ISP, and Joe User needs to be able to dial up and connect, get his email, and ftp content up to his webspace. The wrong way to handle this is to give Joe User a full user account on the servers (or, worse, an account in ActiveDirectory or the equivalent that will authenticate on all the systems on the network). The right way to handle this is to set his password in the dialup listener's configuration, the POP3 server's configuration, and the ftp server's configuration. (This can be automated.) He doesn't need an account on the operating system, doesn't need the ability to shell in, et cetera. Now if Joe User selects an insecure password, he's risking his own stuff and little else. Since he doesn't have an account at the operating system level, his password is less helpful for breaking into the system than it otherwise would be. Joe's password and a local root exploit no longer can necessarily be combined to yield root access.
"It was the best of times, it was the worst of times." is a horrifically bad passphrase. In any brute-force attack, it would be one of the first couple of hundred things tried (assuming the attacker knows you use a passphrase and doesn't start trying 6-8 character passwords first). Much better would be something like "George always kicks his pet spider in the shins." or "Hurry, Larry, bring the glue quick, before the wind blows the broken pieces away!" or "Shiver me timbers, I've never seen so many dabloons in one vault before." or "Scrub the spot gently; you wouldn't want to wear clean through the skin." or "In a magenta submarine we all live. Like yellow I do not, Hmm?"
> Surely by this point in software development it should be regarded as > standard for every program to LOCK access for a given account after X > consecutive failed logon attempts?
No, that opens you up to really easy denial-of-service attacks. The correct way to handle this is to enforce a minimum delay between retries. Bonus points if the exact length of the delay varies or is chosen at random.
> If the security of word-word-word isn't good enough for you, you might > consider word-word-word-word
Or, even better, stick with word-word-word and add ten seconds to the minimum delay between retries. Ten seconds is long enough to annoy a user who has just mistyped his password, but the annoyance passes in just a minute. To a brute-forcer, ten seconds per iteration is almost thirty thousand millenia to exhaust all the possibilities on word-word-word, much more than a mere annoyance.
As I calculated upthread, CVCVCVCV (in uniform case) is about as hard to break as word-word, but about as easy to remember as word-word-word. word-word-word is tens of thousands of times harder to break and an excellent choice. A string of eight case-sensitive letters and numbers, which is traditional, is about two and a half times harder to break than word-word-word, but it's more than two and a half times as likely to land on a sticky note, IMO. If the security of word-word-word isn't good enough for you, you might consider word-word-word-word, which is quite hard to brute force with today's hardware yet still IMO easier to remember than eight random case-sensitive characters.
# Or, if you don't like typing 15+ lines to do something simple... sub v { my @v = qw (a e i o u); $v[rand@v]; } sub c {my@c=split//,'bcdefghjklmnpqrstvwxyz'; $c[rand@c]} print((map {c() . v()} 1..4), c(), "\n");
This is really too basic, though; it significantly reduces the difficulty of brute-forcing the password. Granted, that's better than making it so hard to remember that people write it down, but we can do better. By throwing in blends and dipthongs, it's possible to generate pronounceable passwords that are harder to break.
Even better, though...
open WORDS, "</usr/share/dict/words"; my @w = map { chomp; $_ } <WORDS>; close WORDS; print join '-', map {$w[rand@w]}1..3; print "\n";
Given 45425 words in that file (Mandrake 9.2), that gives us a password generator with 45425^3 = 93731336140625 possible combinations. The other method gives 21^5 * 5^4 = only 2552563125, many times fewer possibilities. Yet, which is easier to remember, "iron-balconies-noninverting" or "dewuyefer"? They're about equally hard to remember, IMO. So going with dictionary words is actually better for security, as long as you string three or more of them together. (Two words gives you 2063430625, about as many possible combinations as the CVCVCVCVC algorithm. AOL uses this for their account passwords, but the horrible thing that happens if someone breaks one of those is they can steal internet access. For things that need real security, I recommend 3 words or more.)
> Buy misspellings of their domain, then capture all emails you receive. Hours > of fun!
Hours of *what*? I think all you'd get out of that is reading email that was written by people stupid enough to believe grandiose and transparently false claims and spend money on a useless service. It is extraordinarily unlikely that even 1% of the email you would get that way would be worth your time to read, much less hours of fun.
> wouldn't it be better to capture the data sent by Outlook and OE's read > receipts and implement something compatible in Mozilla and other email > clients.
You do realise that read receipts were standard before there was any such thing as Microsoft Outlook, right? Almost all mail clients support them, but almost all mail clients have the feature turned off or severely limited by default. These days the reason to turn them off would be spam, but at the time that was pretty much a non-issue, but nevertheless by 1995 almost all mail clients had the feature turned off by default because of privacy concerns; a lot of people didn't *want* the sender to know when they read the message, since sometimes they might read it hurriedly once but not have time to respond, and come back and answer later, and they didn't want the sender to think they were just being rude. This used to be a hot debate topic on the internet circa 1994, but once spam became common the debate faded into obscurity; today almost nobody wants the sender to automatically know when or whether they read the message.
> For messages marked unread, you can NEVER know whether it was opened or not.
Whether it's marked read or unread is totally irrelevant; the only issue at stake is whether the recipient's mail client does something that contacts something on the sender's (or tracking service's) side, such as load linked remote content. If the client does do that, and then the user marks the message as unread, the sender will still think they read it. OTOH, if the client doesn't do anything like that (as most don't), then the user can read it, mark it as read, print a hard copy, copy and paste the contents into a weblog, and discuss it on a major mailing list (say, perl6-language), and the sender has no way to know (unless he visits the recipient's house and looks in his mailbox, digs through the trash and finds the hard copy, or reads the weblog or the mailing list).
> Where I would have an issue is with the small percentage of emails that they > can't track due to clients forcing text only mail. If a user was to build a > strong reliance on this service, they would only assume that the receiver had > never even read their email when in actual fact they could've opened it in a > text-only client and pored over it for days!
One imagines the user (if _remotely_ clueful) would be divested of this misunderstanding after receiving replies to messages that ostensibly were not read. If they correspond with anyone who's even a little bit choosy about software, this would happen sooner rather than later. However, if *everyone* they know uses Outlook or webmail, I can see that some users might remain unaware for quite some time.
> Their server will then send it to the users' server
Additionally, even the recipient's mail server (at the recipient's ISP, usually) does not know when (or if) the recipient reads the message. Well, maybe with IMAP, but not with POP3. The protocol really only handles retrieval, and almost all mail clients just retrieve all the messages in batch, and the user can read them whenever: right away, minutes later, months later, whenever. There is no provision in the POP3 protocol (or AFAIK any of the various extensions, most of which are in any case not supported by most servers and many of which are also not supported by most clients) for the server to be contacted when this happens. I've personally implemented the server side of the POP3 protocol and can attest that there is no provision for this.
So even the user's own ISP's mail server only knows when the user's computer retrieves the message, not when it's read.
The only way the service could work, then, is if the client does something to let the service know that the message has been read. That absolutely requires support from the client, support MOST mail clients do not provide. I imagine they're relying on a feature that is common to Outlook and the most popular webmail services, but in any case the "works regardless of mail cient" claim is obviously without any merit.
You're assuming he would prefer to view the message HTML-formatted rather than in plaintext, which for most users who know the difference is not the case.
Viewing in plain text has the advantage of providing a consistent look and feel for every message, always using the reader's preference for fonts and colors, among other things. (There are a few exceptions, but most people prefer the fonts and colors *they* like over the ones other people want them to see, except in special circumstances such as when having a discussion about fonts and colors.)
It's all moot for me; I use Gnus. Currently I have it set to only display text/plain parts and show anything else as an attachment, which I can save and view if I choose. This means HTML mail has the From and Subject fields to convince me it's not spam. It's been years since I received an HTML message that wasn't spam, incidentally, and I get a *lot* of mail. I do sometimes receive multipart/alternative messages that aren't spam, but the plain text part always shows fine in that case.
I *could* configure Gnus to display HTML parts, using W3, or to launch a browser, such as Mozilla, but I choose not to configure it that way because I prefer to view the plaintext alternative, and like I said it's been years since I received an HTML-only message that wasn't unsolicited bulkmail.
Back to topic, the didtheygetit.com claim that the service works regardless of what client the recipient uses is obviously not only bogus for their specific product but in fact a totally impossible thing for any product to deliver, unless the content is munged into a form that they are *unable* to view without alerting you, such as an executable that unencrypts and displays the text after phoning home -- but something like that would be so odious to so many recipients that the sender would by using it be decreasing significantly the chances that the message would be read at all, which would rather defeat the purpose of the whole idea. In other words, it's an utterly impossible thing to deliver. OTOH, they only claim it works in 98% of cases and carefully qualify this saying "in our testing", which presumably means they didn't test with geeks who use carefully selected high-quality mail readers; they probably tested mostly with Outlook, two or three popular webmail services, and maybe Eudora or Netscape. I can positively guarantee that it would never work with Pegasus Mail (though pmail *does* support read receipts, but only if the user has turned them on in the prefs; they're off by default), and obviously it doesn't work with my particular config of Gnus. (I don't know about a default Gnus config, but that's largely not a significant issue since people who leave settings at their defaults don't tend to use Gnus in the first place; it's very much geared toward people who like to change lots of options.) Clearly it also wouldn't work with mutt or pine or anything like that, and *obviously* it wouldn't work if the user talks to the POP3 server directly (which I happen to have just done yesterday, though I only looked at three or four messages that way, and I'm atypical, being the maintainer of the Net::Server::POP3 module).
I can imagine that it might be useful to some people nonetheless, especially in a largely homogenous corporate environment wherein it is predictable what mail client everyone or almost everyone uses. But clearly they're very much exaggerating (at best) when they claim it works irrespective of the client.
When TNG was first started, the people producing it were thinking of it as just another TOS clone, and a take-off at that. They only expected it to run for a season or two. It was after it became really popular that they realised they actually had something and started working to give it its own identity and some quality. Right about the middle of the second season, you can see the changes start, as they started transitioning it from a TOS knock-off to a real show. About this time they killed off Yarr (not because Yarr was bad but because they wanted to make room for Warf on the bridge, clearly a good move in retrospect), traded out Polaski for Crusher (this one I'm not so sure was as good a decision, but it ended up working out okay), got rid of the clown they had as chief engineer and promoted Geordi, started doing a lot more to build up the repertoire of alien races so it wouldn't be the same enemies every episode, started handling the holodeck a little differently (using it as a plot device instead of just a cool new gadget to show off), did some work on costuming and prop quality, and so on and so forth. By the third season, it was a very different program.
> He may not be the best actor, but I always thought he did ok in Star Trek.
It was Shatner who held Star Trek back from real greatness. Star Trek was popular in the sixties because it was so much better than the sci-fi of the day (think: Doctor Who) and because of the cool geek characters such as Spock and Scotty. Kirk was always an annoyance, tollerated because, well, the ship had to have a captain.
This is why TNG was so much better than TOS. The closest thing to Kirk (in terms of the character) was Ricart, but he was played by a pretty decent actor, much better than Shattner. The worst actors in TNG were all one-episode characters and never heard from again. Picard was in some ways not as interesting a character as Kirk, but the acting was so much better it was a huge relief, and anyway it's not the captain who makes the show popular with geeks, it's the engineers science officers and so on e.g. Data and Geordi.
You forgot the parts about their bodies being cut into pieces and licked by wild dogs and eaten by carion birds and their houses turned into piles of rubble and their cities rained upon with brimstones and their journey through life henceforward being without stops and their bladders always full and their children and their children's children making war in the back seat and the famine and the locusts and the pestilence and cafeteria food and thousand pound senior citizens in white spandex...
> Expand more on hardware. Microsoft hardware, contrary to their software, > is very good stuff imho.
Some of it is, yes. Microsoft is one of the two companies whose mice I've been really pleased with (the other being Mitsumi), and they make pretty decent keyboards (although I, being *very* picky, use an Avant model, which is better but also correspondingly more expensive).
Their other hardware may be good too, but I don't have experience with it.
Microsoft could also stand to expand more in other, unrelated business areas. Diversification, you know. I'm not talking about other content production areas like media -- that would have too many antitrust-law implications -- but rather unrelated areas. Buy up a couple of popular local fast food chains and take them nationwide (or international), that sort of thing. I'm sure they do some of this sort of thing by investing in stocks and whatnot, but I really think they ought to do more of it. If nothing else, it would be an unobvious way to hedge their bets in the long term on the commoditization of software without looking like they're doing so.
Slashdot Mirror
> In fairness, the Advanced Bash Scripting Guide here is a great resource
> for people wanting a good reference to bash scripting and shell scripting
> in general.
The documentation for bash is good, but the previous poster was talking about
plain vanilla traditional back-in-the-day-style bourne shell scripting, the
kind where you don't use any bash-specific features or other non-portable
stuff. bash is fine if you only have to support Linux systems, cygwin, and
the modern BSDs maybe, but it's not ubiquitous enough to achieve the kind of
real portability (among *nix systems) that people use plain vanilla bourne
shell scripting for.
Perl is *significantly* more widely ubiquitous than bash (to the extent that
it's pretty unusual to find a system with bash and no perl, but the reverse
is not at all unusual), and if you count non-*nix systems it's probably these
days more widely deployed even than sh. So in terms of portability, writing
core Perl that doesn't require anything more recent than 5.003 is actually a
pretty good option.
Of course if you want *real* portability you write in Inform and compile to
the z-machine, preferably version 3... [mutters something incoherent about
Perl not running on TRS80 or Nintendo Gameboy]
> I always thought, liberal or conservative, it made more sense to AUTOMATE
> the federal tax by eliminating the paperwork and going to a sales tax model
> (excepting food and medicine of course), and if the overhead was 5-10%
> instead of 40% that's quite an improvement.
The liberals would never go for that, for several reasons. First, a smaller
IRS means fewer people on government payroll. Second, you're effectively
charging everyone the same tax rate and, importantly, this is obvious.
Income tax allows you to charge higher-income people more tax, and that has
always been an important feature of the liberal viewpoint on taxes. Third,
everyone would see how much they're paying every single time they buy
anything. Currently you see part of the picture when you buy something, part
of the picture when you look at your paycheck stub, et cetera. It's all
broken up, so you don't realize how much of your money you're giving up.
Personally, I'd vote for a system of sales and excise taxes in a heartbeat,
but they're not asking me.
> Why do trains in the wide open midwest not make sense?
Because the standard deviation of population density is too low. There are
relatively few really large cities, quite a few medium-sized cities, and a
hillion jillion quadrillion small cities. The small cities collectively
contain most of the population. The number of possible points of origin and
destination for a trip, then, are too large compared to the number of trips
taken.
Sure, there are lines that would be worth running, such as from Mansfield
to Columbus, Mansfield to Cleveland, Cleveland to Toledo, Toledo to Chicago,
Cleveland to Youngstown, Youngstown to Buffalo, Youngstown to Pittsburgh,
Columbus to Cincinatti, Cincinatti to Indianapolis, and so on -- but these
comprise a rediculously small percentage of the trips people take by car;
putting in all of the mentioned lines would have very little impact on the
number of miles driven by car in Ohio.
> I'd recommend installing gentoo.
Yes, but *not* on the production systems! Install Gentoo on a workstation
or a spare system or something, for the learning experience, but keep the
production systems on a less bleeding-edge distribution. Seriously. I like
Gentoo, but it tends to pick up quite new versions of things before they've
been hammered on for very long.
> Next step (and here's where I actually get into answering your question):
> Learn (bourne) shell scripting.
I have a different suggestion here. If you were going to be administering a
bunch of older, proprietary Unix systems, this would be sound advice, for sure.
However, the OP seems to indicate that everything in question is at least
somewhat close to modern and open to the concept of upgrades. In that kind
of environment, you're not likely to run into a crochety old SunOS box that
can't be upgraded to Solaris because of application compatibility and doesn't
have space on the disk for an upgrade of Perl to version 5. What you are
likely to have is Perl 5.005 or later (*probably* 5.6 or later) on every
single system. Given that, shell scripting starts to look like a quite lousy
option. The documentation is poor and poorly organized, since it's scattered
across myriad utilities (awk, sed, and so on and so forth), each of which has
a handful of mostly-standard options and a whole bunch of extended options
that vary just a bit from distribution to distribution. You can't use the
man pages for reference, because you'll end up doing something that breaks
when you try to run it on BSD. There are books on portable shell scripting,
but Perl is much more consistent and the books are better. If you already
know shell scripting, that's fine, but if you don't, and if you don't have
to work with antequated systems, learning it now is probably a waste of time,
mostly, time that you could be spending learning something else. Get a copy
of the camel book and be happy.
# One last improvement -- actually go to a result page:& ie=UTF-8&oe=UTF-8&q=$a+$b&btnG=Google+Search") ; /\d+k/i } /[^A-Za-z0-9, -]/, $t->as_text(); /\s+/, $s[rand@s]; /^\s*$/ } map { s/\W//g; $_ } @token;
print "Google "; {
use WWW::Mechanize; use HTML::TreeBuilder;
open WORDS, "</usr/share/dict/words";
my @w = map { chomp; $_ } <WORDS>; close WORDS;
($a, $b, my $phrase) = map {$w[rand@w]} 1..2;
print "$a $b | mung2: \t";
while (not $phrase) {
my $browser = WWW::Mechanize->new();
$browser->get("http://www.google.com/search?hl=en
$browser->follow_link(n => 10); # Tenth link is first result (currently).
my $content = $browser->content(); my $t = HTML::TreeBuilder->new()->parse($content);
my @s = grep { length $_ > 25 and length $_ < 200 and not
split
my @token = split
$phrase = ucfirst lc join "_", grep { not
}
print "$phrase\n";
}
# This is better:& ie=UTF-8&oe=UTF-8&q=$a+$b&btnG=Google+Search") ; /[^A-Za-z0-9, -]/, /\s+/, $s[rand@s]; /^\s*$/ } map { s/\W//g; $_ } @token;
print "Google word word | mung2: \t"; {
use WWW::Mechanize; use HTML::TreeBuilder;
open WORDS, "</usr/share/dict/words";
my @w = map { chomp; $_ } <WORDS>; close WORDS;
($a, $b, my $phrase) = map {$w[rand@w]} 1..2;
while (not $phrase) {
my $browser = WWW::Mechanize->new();
$browser->get("http://www.google.com/search?hl=en
my $content = $browser->content(); my $t = HTML::TreeBuilder->new()->parse($content);
my @s = grep { length $_ > 25 and length $_ < 200 } split
$t->as_text(); my @token = split
$phrase = join "_", grep { not
}
print "$phrase\n";
}
> Personally, I was working on a program for generation of passwords from
/usr/share/dict/words, Google for them,
& ie=UTF-8&oe=UTF-8&q=$a+$b&btnG=Google+Search") ; /g; my @token = split /\s+/, lc $_;
> fortune, so that things are handled consistently, but I've stalled the
> idea until I get get it to use a significantly larger basis for the
> mnemonics (as if you knew the source of the mnemonics, and the rules for
> generating passwords, it's just as easy to brute force as a dictionary
> attack)
Idea: Take two random words from
yank a phrase out of the result, and mung it according to your rules...
#!/usr/bin/perl
print "VCVCVC: \t"; {
sub v { my @v = qw (a e i o u); $v[rand@v]; }
sub c {my@c=split//,'bcdefghjklmnpqrstvwxyz'; $c[rand@c]}
print((map {c() . v()} 1..4), c(), $/);
}
print "word-word-word: \t"; {
open WORDS, "</usr/share/dict/words";
my @w = map { chomp; $_ } <WORDS>; close WORDS;
print join '-', map {$w[rand@w]}1..4; print "\n";
}
print "Google word word | mung: \t"; {
open WORDS, "</usr/share/dict/words";
my @w = map { chomp; $_ } <WORDS>; close WORDS;
($a, $b) = map {$w[rand@w]} 1..2;
use WWW::Mechanize; use HTML::TreeBuilder;
my $browser = WWW::Mechanize->new();
$browser->get("http://www.google.com/search?hl=en
my $content = $browser->content(); my $t = HTML::TreeBuilder->new()->parse($content);
$_ = $t->as_text(); s/\W/
my $idx = rand(@token) - 7; my $phrase = join "_", @token[$idx+1..($idx+6)];
print "$phrase\n";
# use Data::Dumper; print Dumper(\@token) . $/;
}
# Results:
# edu_campus_hook_the_official_college
# nationalist_community_the_khazar_theory_by
# seemed_to_make_jirov_angry_and
# 3_he_rested_from_all_the
This was very quick. You could do your phrase-choosing and munging differently.
Dunno. The only foreign language I know much of is Common Greek, and this
technique is somewhat less useful with Common Greek than Korean, since many
Common Greek words have a fairly direct English cognate. For example, "Many
Common Greek words have" comes out as something like "polus logoi Koine echo";
the first word "polus" (much/many) AFAIK does not have a cognate, but the next
two do, and "echo" is a false cognate, I think. (The english word "echo" does
come from a Greek word, but it's a different and probably unrelated word.)
You see the problem. It doesn't look directly like English words, but if
the password rules are looking for English roots with the endings mangled to
reject stuff like "basket47", they're going to alarm on "logoi" for sure and
*possibly* "Koine" as well (depending on how loose the matching is), and of
course "echo" won't go through if there's any checking at all.
> For example, I have to supply uid/pwd in order to read the Washington Post
> (my local newspaper). Is it important to keep this password secret?
No, but it's not important to the Washington Post that you keep it secret,
either. If someone steals the password, they could (gasp) read the paper.
An important trick in the security toolbag is to give users the priveleges
they actually need and no more. Let's say you're an ISP, and Joe User needs
to be able to dial up and connect, get his email, and ftp content up to his
webspace. The wrong way to handle this is to give Joe User a full user
account on the servers (or, worse, an account in ActiveDirectory or the
equivalent that will authenticate on all the systems on the network). The
right way to handle this is to set his password in the dialup listener's
configuration, the POP3 server's configuration, and the ftp server's
configuration. (This can be automated.) He doesn't need an account on
the operating system, doesn't need the ability to shell in, et cetera.
Now if Joe User selects an insecure password, he's risking his own stuff
and little else. Since he doesn't have an account at the operating system
level, his password is less helpful for breaking into the system than it
otherwise would be. Joe's password and a local root exploit no longer can
necessarily be combined to yield root access.
"It was the best of times, it was the worst of times." is a horrifically bad
passphrase. In any brute-force attack, it would be one of the first couple
of hundred things tried (assuming the attacker knows you use a passphrase
and doesn't start trying 6-8 character passwords first). Much better would
be something like "George always kicks his pet spider in the shins." or
"Hurry, Larry, bring the glue quick, before the wind blows the broken pieces
away!" or "Shiver me timbers, I've never seen so many dabloons in one vault
before." or "Scrub the spot gently; you wouldn't want to wear clean through
the skin." or "In a magenta submarine we all live. Like yellow I do not, Hmm?"
> Surely by this point in software development it should be regarded as
> standard for every program to LOCK access for a given account after X
> consecutive failed logon attempts?
No, that opens you up to really easy denial-of-service attacks. The correct
way to handle this is to enforce a minimum delay between retries. Bonus
points if the exact length of the delay varies or is chosen at random.
> If the security of word-word-word isn't good enough for you, you might
> consider word-word-word-word
Or, even better, stick with word-word-word and add ten seconds to the minimum
delay between retries. Ten seconds is long enough to annoy a user who has
just mistyped his password, but the annoyance passes in just a minute. To a
brute-forcer, ten seconds per iteration is almost thirty thousand millenia
to exhaust all the possibilities on word-word-word, much more than a mere
annoyance.
As I calculated upthread, CVCVCVCV (in uniform case) is about as hard to break
as word-word, but about as easy to remember as word-word-word. word-word-word
is tens of thousands of times harder to break and an excellent choice. A
string of eight case-sensitive letters and numbers, which is traditional,
is about two and a half times harder to break than word-word-word, but it's
more than two and a half times as likely to land on a sticky note, IMO. If
the security of word-word-word isn't good enough for you, you might consider
word-word-word-word, which is quite hard to brute force with today's hardware
yet still IMO easier to remember than eight random case-sensitive characters.
# Or, if you don't like typing 15+ lines to do something simple...
sub v { my @v = qw (a e i o u); $v[rand@v]; }
sub c {my@c=split//,'bcdefghjklmnpqrstvwxyz'; $c[rand@c]}
print((map {c() . v()} 1..4), c(), "\n");
This is really too basic, though; it significantly reduces the difficulty of
brute-forcing the password. Granted, that's better than making it so hard
to remember that people write it down, but we can do better. By throwing in
blends and dipthongs, it's possible to generate pronounceable passwords that
are harder to break.
Even better, though...
open WORDS, "</usr/share/dict/words";
my @w = map { chomp; $_ } <WORDS>; close WORDS;
print join '-', map {$w[rand@w]}1..3; print "\n";
Given 45425 words in that file (Mandrake 9.2), that gives us a password
generator with 45425^3 = 93731336140625 possible combinations. The other
method gives 21^5 * 5^4 = only 2552563125, many times fewer possibilities.
Yet, which is easier to remember, "iron-balconies-noninverting" or
"dewuyefer"? They're about equally hard to remember, IMO. So going with
dictionary words is actually better for security, as long as you string
three or more of them together. (Two words gives you 2063430625, about
as many possible combinations as the CVCVCVCVC algorithm. AOL uses this
for their account passwords, but the horrible thing that happens if someone
breaks one of those is they can steal internet access. For things that
need real security, I recommend 3 words or more.)
> Buy misspellings of their domain, then capture all emails you receive. Hours
> of fun!
Hours of *what*? I think all you'd get out of that is reading email that was
written by people stupid enough to believe grandiose and transparently false
claims and spend money on a useless service. It is extraordinarily unlikely
that even 1% of the email you would get that way would be worth your time to
read, much less hours of fun.
> wouldn't it be better to capture the data sent by Outlook and OE's read
> receipts and implement something compatible in Mozilla and other email
> clients.
You do realise that read receipts were standard before there was any such
thing as Microsoft Outlook, right? Almost all mail clients support them,
but almost all mail clients have the feature turned off or severely limited
by default. These days the reason to turn them off would be spam, but at
the time that was pretty much a non-issue, but nevertheless by 1995 almost
all mail clients had the feature turned off by default because of privacy
concerns; a lot of people didn't *want* the sender to know when they read
the message, since sometimes they might read it hurriedly once but not have
time to respond, and come back and answer later, and they didn't want the
sender to think they were just being rude. This used to be a hot debate
topic on the internet circa 1994, but once spam became common the debate
faded into obscurity; today almost nobody wants the sender to automatically
know when or whether they read the message.
> For messages marked unread, you can NEVER know whether it was opened or not.
Whether it's marked read or unread is totally irrelevant; the only issue at
stake is whether the recipient's mail client does something that contacts
something on the sender's (or tracking service's) side, such as load linked
remote content. If the client does do that, and then the user marks the
message as unread, the sender will still think they read it. OTOH, if the
client doesn't do anything like that (as most don't), then the user can read
it, mark it as read, print a hard copy, copy and paste the contents into a
weblog, and discuss it on a major mailing list (say, perl6-language), and
the sender has no way to know (unless he visits the recipient's house and
looks in his mailbox, digs through the trash and finds the hard copy, or
reads the weblog or the mailing list).
> Where I would have an issue is with the small percentage of emails that they
> can't track due to clients forcing text only mail. If a user was to build a
> strong reliance on this service, they would only assume that the receiver had
> never even read their email when in actual fact they could've opened it in a
> text-only client and pored over it for days!
One imagines the user (if _remotely_ clueful) would be divested of this
misunderstanding after receiving replies to messages that ostensibly were not
read. If they correspond with anyone who's even a little bit choosy about
software, this would happen sooner rather than later. However, if *everyone*
they know uses Outlook or webmail, I can see that some users might remain
unaware for quite some time.
> Their server will then send it to the users' server
Additionally, even the recipient's mail server (at the recipient's ISP,
usually) does not know when (or if) the recipient reads the message. Well,
maybe with IMAP, but not with POP3. The protocol really only handles
retrieval, and almost all mail clients just retrieve all the messages in
batch, and the user can read them whenever: right away, minutes later,
months later, whenever. There is no provision in the POP3 protocol (or
AFAIK any of the various extensions, most of which are in any case not
supported by most servers and many of which are also not supported by most
clients) for the server to be contacted when this happens. I've personally
implemented the server side of the POP3 protocol and can attest that there
is no provision for this.
So even the user's own ISP's mail server only knows when the user's computer
retrieves the message, not when it's read.
The only way the service could work, then, is if the client does something
to let the service know that the message has been read. That absolutely
requires support from the client, support MOST mail clients do not provide.
I imagine they're relying on a feature that is common to Outlook and the
most popular webmail services, but in any case the "works regardless of mail
cient" claim is obviously without any merit.
You're assuming he would prefer to view the message HTML-formatted rather than
in plaintext, which for most users who know the difference is not the case.
Viewing in plain text has the advantage of providing a consistent look and
feel for every message, always using the reader's preference for fonts and
colors, among other things. (There are a few exceptions, but most people
prefer the fonts and colors *they* like over the ones other people want them
to see, except in special circumstances such as when having a discussion
about fonts and colors.)
It's all moot for me; I use Gnus. Currently I have it set to only display
text/plain parts and show anything else as an attachment, which I can save
and view if I choose. This means HTML mail has the From and Subject fields
to convince me it's not spam. It's been years since I received an HTML
message that wasn't spam, incidentally, and I get a *lot* of mail. I do
sometimes receive multipart/alternative messages that aren't spam, but the
plain text part always shows fine in that case.
I *could* configure Gnus to display HTML parts, using W3, or to launch a
browser, such as Mozilla, but I choose not to configure it that way because
I prefer to view the plaintext alternative, and like I said it's been years
since I received an HTML-only message that wasn't unsolicited bulkmail.
Back to topic, the didtheygetit.com claim that the service works regardless
of what client the recipient uses is obviously not only bogus for their
specific product but in fact a totally impossible thing for any product to
deliver, unless the content is munged into a form that they are *unable*
to view without alerting you, such as an executable that unencrypts and
displays the text after phoning home -- but something like that would be so
odious to so many recipients that the sender would by using it be decreasing
significantly the chances that the message would be read at all, which would
rather defeat the purpose of the whole idea. In other words, it's an utterly
impossible thing to deliver. OTOH, they only claim it works in 98% of cases
and carefully qualify this saying "in our testing", which presumably means
they didn't test with geeks who use carefully selected high-quality mail
readers; they probably tested mostly with Outlook, two or three popular
webmail services, and maybe Eudora or Netscape. I can positively guarantee
that it would never work with Pegasus Mail (though pmail *does* support read
receipts, but only if the user has turned them on in the prefs; they're
off by default), and obviously it doesn't work with my particular config
of Gnus. (I don't know about a default Gnus config, but that's largely not
a significant issue since people who leave settings at their defaults don't
tend to use Gnus in the first place; it's very much geared toward people
who like to change lots of options.) Clearly it also wouldn't work with
mutt or pine or anything like that, and *obviously* it wouldn't work if
the user talks to the POP3 server directly (which I happen to have just
done yesterday, though I only looked at three or four messages that way,
and I'm atypical, being the maintainer of the Net::Server::POP3 module).
I can imagine that it might be useful to some people nonetheless, especially
in a largely homogenous corporate environment wherein it is predictable what
mail client everyone or almost everyone uses. But clearly they're very much
exaggerating (at best) when they claim it works irrespective of the client.
When TNG was first started, the people producing it were thinking of it as just
another TOS clone, and a take-off at that. They only expected it to run for a
season or two. It was after it became really popular that they realised they
actually had something and started working to give it its own identity and some
quality. Right about the middle of the second season, you can see the changes
start, as they started transitioning it from a TOS knock-off to a real show.
About this time they killed off Yarr (not because Yarr was bad but because they
wanted to make room for Warf on the bridge, clearly a good move in retrospect),
traded out Polaski for Crusher (this one I'm not so sure was as good a decision,
but it ended up working out okay), got rid of the clown they had as chief
engineer and promoted Geordi, started doing a lot more to build up the
repertoire of alien races so it wouldn't be the same enemies every episode,
started handling the holodeck a little differently (using it as a plot device
instead of just a cool new gadget to show off), did some work on costuming
and prop quality, and so on and so forth. By the third season, it was a
very different program.
> He may not be the best actor, but I always thought he did ok in Star Trek.
It was Shatner who held Star Trek back from real greatness. Star Trek was
popular in the sixties because it was so much better than the sci-fi of the
day (think: Doctor Who) and because of the cool geek characters such as Spock
and Scotty. Kirk was always an annoyance, tollerated because, well, the ship
had to have a captain.
This is why TNG was so much better than TOS. The closest thing to Kirk (in
terms of the character) was Ricart, but he was played by a pretty decent
actor, much better than Shattner. The worst actors in TNG were all
one-episode characters and never heard from again. Picard was in some ways
not as interesting a character as Kirk, but the acting was so much better it
was a huge relief, and anyway it's not the captain who makes the show popular
with geeks, it's the engineers science officers and so on e.g. Data and Geordi.
You forgot the parts about their bodies being cut into pieces and licked by
wild dogs and eaten by carion birds and their houses turned into piles of
rubble and their cities rained upon with brimstones and their journey through
life henceforward being without stops and their bladders always full and
their children and their children's children making war in the back seat and
the famine and the locusts and the pestilence and cafeteria food and thousand
pound senior citizens in white spandex...
> Expand more on hardware. Microsoft hardware, contrary to their software,
> is very good stuff imho.
Some of it is, yes. Microsoft is one of the two companies whose mice I've
been really pleased with (the other being Mitsumi), and they make pretty
decent keyboards (although I, being *very* picky, use an Avant model, which
is better but also correspondingly more expensive).
Their other hardware may be good too, but I don't have experience with it.
Microsoft could also stand to expand more in other, unrelated business areas.
Diversification, you know. I'm not talking about other content production
areas like media -- that would have too many antitrust-law implications --
but rather unrelated areas. Buy up a couple of popular local fast food
chains and take them nationwide (or international), that sort of thing.
I'm sure they do some of this sort of thing by investing in stocks and
whatnot, but I really think they ought to do more of it. If nothing else,
it would be an unobvious way to hedge their bets in the long term on the
commoditization of software without looking like they're doing so.