Oh, yeah, I forgot about turkey. Practically all Americans will eat turkey -- its acceptance level as food is at roughly the same level as chicken or pork. It isn't eaten as often, but that's due to a combination of its being more expensive most of the time and its normally being sold as a whole turkey, which is too much for a single meal for most families. (Chicken is normally sold broken down into pieces, which is more convenient on a day-to-day basis. You can also buy a whole chicken, but it's less common, not to mention much smaller than a turkey anyway.)
> Americans, who are the most sentimental people in the world when it comes to animals, eat meat > only through a process of denial. My sister in law was feeding her boys "Chicken Fingers", and > the older boy mimed chopping off his fingers, saying "Thwack!, Cluck, cluck, cluck!". "Oh, > Jeffry," the other replied, "it's not that kind of chicken."
Not all Americans are that dumb. (I suspect most would tell the boy something more along the lines of "Don't be disgusting" or perhaps "It's not that kind of fingers.") And while Americans are very sentimental about *pets*, most have no qualms at all about eating cows, chickens, or pigs.
Admittedly, if you offer an American meat from some *other* kind of animal, you're liable to get a less than enthusiastic reaction a fair percentage of the time.
At least 60% of American men (probably more) and a significant minority of American women will eat fish, though this tends to be limited to certain *types* of fish, most notably perch, catfish, salmon, tuna, whiting (the kind of fish in "fish sticks" and "Filet O Fish" and such), trout, bass, walleye, and panfish. In some regions there are additions to this list, e.g., in Michigan they eat muskellunge. Carp is also known as a food but is closely associated with a specific ethnic group; most other people won't touch it. There are a small handful of other seafood items that a significant minority of Americans will eat too, mainly shrimp and lobster, but near the coasts also crab and oyster and such.
Also a significant minority of Americans will also eat traditional "hunting" animals (rabbit, deer, squirrel,...), and a small percentage of Americans will also brave marginally less common farm animals (sheep, goat,...).
But when you start talking about eating pretty much anything that moves, you can easily get into territory where most of the population will consider you looney. Just *suggesting* that people could eat reptiles will get you some pretty shocked looks, for instance.
Actually, the method I've heard of for dealing with obnoxious cats is to leave small pieces of sponge soaked in fish oil sitting around all the time. I've never tried it, so I can't personally verify the effectiveness.
> I'll grant, a rootkit could conceal itself better with root access, but I doubt very many people > would notice an extra process running anyways. (I think I'd call my trojan "bash").
I'll go you one better: the installer can just check the current process table at install time, make a list of anything the user's running multiple copies of, pick one of them at random, and name the trojan executable that. So if the user's got three copies of Emacs running at the time the thing installs, the trojan could end up being named emacs, but on a vi user's system it would be named something else. Similarly, it could be named bash on a bash user's system, but if the user had changed his default shell to tcsh or whatnot, then the trojan would not be named bash. This tactic should help the thing blend in better on process lists and escape casual, accidental detection most of the time.
The user could potentially still discover it, e.g. by finding the cronjob (or the line in.bash_profile, or the gnome-session entry, or whatever) that sets the thing running each session. But if 80% of users don't find it for over three months and 50% don't find it for over a year, the malware could build up a pretty sizeable installed base (especially in the proposed fantasy world where *nix systems (counting OS X) are 67% of the world's desktops).
Of course, that's in the absense of anti-malware software making a concerted effort to detect such things. Unix-like systems on the whole don't need traditional anti-virus software (in the sense of protecting against file viruses) because system permissions (assuming the user doesn't normally run as root) effectively thwart that kind of malware anyway. But trojans and other social-engineering attacks are altogether another thing. There are intrusion detection systems, of course, in just about every major distro, but I think most users of the distros in question don't really know how to use them, as they currently stand. (I only recently studied up on how to use chkrootkit and rkhunter myself, and I think there are other types of IDS that I still haven't studied up on. I first started using Linux systems in 1998...)
> Which environment would a trojan/botnet writer target and why?
They would (and do) target all of them.
That doesn't imply that they all are (or would be) equally insecure, however.
Re:Not the ol' backwards compatibility excuse agai
on
IE 8 Passes Acid2 Test
·
· Score: 1
> If it's the problem of a site seeing IE8 and then running IE6 code hacks, then they could > just rename the whole browser to something cool like Expanse 1.0 or something
I wonder about this too. If IE8's interoperable rendering is as much better as they indicate, wouldn't it be an opportune time to (finally) update the user-agent string? IE has been spoofing Mozilla for pretty much its entire history, but is that really still desirable? In the early days spoofing Mozilla meant you got the "enhanced" content intended for Netscape browsers (with, you know, cool colors and stuff). Later other browsers started to spoof the "IE spoofing Mozilla" combination, because that typically meant you got the spiffy DHTML content intended for IE5. Now most other browsers have largely _quit_ doing that, so they can get the more standards-compliant content (and here I'm using the term loosely; said content is seldom fully compliant) typically intended for Firefox. If I were the IE8 team, I'd be taking the opportunity now to update the User-Agent string.
Given that naive sniffing code typically just does a substring check, usually for "IE" and sometimes the version number, the obvious thing is to remove the string "IE" from the UA string. If it were me, I'd make it something along these lines...
Internet Explorer/8.0 (Win32; Windows NT 6.0; en-US)
Rebranded versions (notably, MSN Explorer) could throw whatever vendor indicator they like on the end of that.
Apparently you are not very familiar with game vaporware history. If you were, you would have heard of Daikatana. It turns out that hyping a game for a really long time doesn't necessarily make it successful when you finally do release it. In fact, usually it just turns out to be based on obsolete technology from several years ago, when you started working on it.
> The speedier regex engine is going to be a great boon.
If you say so. My experience has been that the existing regex engine is pretty much never a performance bottleneck for anything I'm doing. (Usually when I do see perf issues it's an I/O bottleneck at fault, typically either the network or the database.)
I'm much more interested in the new features. I'm really looking forward to Perl6, but meanwhile some new features in Perl5 will be nice to have.
> So, he instead went with a thinner, workable cover and cosmetic only gears.
That's fine as far as it goes, but the cosmetic clockwork still should have been laid out in a plausible arrangement. It doesn't bother me as much as the other poster, but I did notice it.
Can we put block-level elements in paragraphs?
on
HTML V5 and XHTML V2
·
· Score: 1
All I want to know about upcoming XHTML versions is, can we finally put block-level elements inside paragraphs? We've been whining about the inability to do this, and basically not _using_ paragraphs as such because we can't, for over a decade. It's, as far as I'm concerned, the *one* problem with XHTML as it stands.
As far as HTML5, I thought XHTML was supposed to *be* HTML5, conceptually if not in name. Having received the benefits of well-formed markup, why would anyone ever want to go back to the old "Maybe this element is inside of that paragraph, or maybe it's after it, depending on where we decide the elided close tag belongs" way of doing things? I for one don't *EVER* want to deal with non-wellformed markup again. Make it go away.
Yeah, that could be topped. Genocide as art springs immediately to mind. Have yourself a nice big old-fashioned ethnic cleansing, and then when the international community starts whining about human rights just tell them that you're a serious artist, and that your work is deeply meaningful in ways that you wouldn't expect hoi polloi to understand.
Note: I am NOT advocating this approach. I'm only saying that it would be more incomprehensible to the masses and more senseless than genetically malapulchrated cloned life as art.
> Someone can *not* sue you for speech, as that uses the courts (a branch > of the government) to silence you, and that is prohibited by the first amendment.
This is incorrect. Someone *can* sue you for speech, or try to at any rate. Whether they'll get anywhere depends on various stuff. For instance, if they can make a coherent argument that your speech might be considered libelous, they'll probably be able to successfully drag you through the courts, and if they can make a _convincing_ argument that your speech _is_ libelous, they can potentially win the case. Libel is not the only kind of speech that they can successfully sue you for, either. Copyright and trademark violations are another example. Fraud is another (and one you can even be prosecuted for criminally, though generally you only will be if you cost the victims something tangible).
When the first amendment says "speech" and "press", it is, in context, clearly talking chiefly about political expression, not absolutely anything that anyone could ever say or write.
Live environments, in addition to being red, should also have been in inverse video. In other words, test environments are bright green on a black background, and live environments are black (or possibly yellow) on a red background.
Though, not having them open at the same time would also probably be a good idea. Just in case some clown gets confused about which window is receiving keyboard input at the moment.
> My productivity has been boosted four fold (not a joke!) compared to > when I was still developing in PHP. *And* my code is now shorter, more > readable, more maintainable, and more secure.
Sure, but that's because Ruby is a real VHLL. You could also have achieved that effect by switching to Perl or, if you don't mind thinking in object-oriented terms about absolutely everything (and can put up with syntactically significant whitespace), Python. That doesn't answer the question about Rails.
Ballistic mosquito nets are designed to protect against not just ordinary, calmly-rational mosquitos, but also against mosquitos that are going all ballistic on you. Which they tend to do when they have you severely outnumbered, because they're afraid you won't have enough blood to go around.
You probably had the good sense to let your laundered flash drive *dry* before attempting to recover the data.
It's amazing how many people, upon realizing that they've inadvertently gotten some piece of electronics wet, immediately panic and cannot resist the urge to test *right now* whether it still works or not. Of course, that's more likely to dammage it than washing it in the first place, but they don't think about that until after they find out whether it works or not.
> I don't claim to understand this at this point, but if so, there are some > things you can create in some places which don't get automatic copyright. > But in that case, I guess you wouldn't get a copyright even if you tried > to register it...
IANAL, but that matches my understanding. In the US, some examples of things that are not copyrightable include very short bits of text (on the order of a couple of words, but note that they _can_ be trademarked), photographic reproductions of two-dimensional art that is in the public domain, and lists of ingredients (it is the instructions in a recipe that are copyrightable, not the ingredients list). I don't know exactly how much this varies from country to country, but there may be some things that are copyrightable in some countries but not in others.
> Outlook and Exchange is highly compelling over any other options
*Are* there other options? Off the top of my head, I don't even know of any other enterprise-class fully automated virus retrieval and installation systems.
> Changing this limitation would require fundamental changes to the underlying > blowfish algorithm, and is hence difficult to do
Ah. That makes sense, and is a good reason. In cryptography, a known algorithm that has been examined in some depth and whose strength is considered a known quantity is almost always preferable to a new algorithm of unknown and untested strength. Of course vulnerabilities (e.g., to deliberate collision generation) are from time to time discovered even in long-established algorithms, but even then usually the dammage is of a relatively mild nature, e.g., the sort of thing that potentially cuts average compromise time in half or so, as opposed to the sort of thing that reduces it a thousand fold. With a new algorithm that has not been investigated in detail by the security community, you have no idea what weakness somebody's going to uncover next week.
> As an aside, they could have done better.
Of course. That's always the case.
> For other hashing schemes, there is no point in using more salt than the size of your password hash.
Okay, but in general, I would argue that...
> (and, per the argument of the OpenBSD crowd, you *ought* have an expensive hash)
Exactly. As I was saying, I would argue that in general it is extremely worthwhile, from a security perspective, to have a hash that's longer and more expensive than you think is actually necessary.
Among other things, weaknesses *are* discovered from time to time in the known algorithms (both the hashing algorithm itself and also other related algorithms, e.g. for encryption, which is used in conjunction with hashing), and while for established algorithms these are seldom fatal, they nevertheless sometimes result in an overall reduction in security. If you're significantly more secure in the first place than you thought you needed to be, this hurts less.
Also, backward compatability concerns occasionally result in something being used *well* past the end of its original projected lifespan, and with advances in processing power (and storage, and networking, and so forth) this has significant implications for security. If you think something will *probably* be used for ten years and *potentially* could be used for as much as thirty years, it's probably best to design it to stand up to new technology for a hundred years or so if possible. Because if it's still secure fifty years after people quit using it, that's all well and good, but if it becomes insecure *while* people are still using it, that's bad. A hundred years is overkill, of course, but overkill is *good* in this context.
That's assuming, of course, that it doesn't create serious usability problems. Trying to implement a password hashing system that will stand up for a hundred years is probably doomed to failure for this reason. With current hardware you'd probably have page swapping going on every time somebody logs in, which would be bad. So fine, you end up backing off from that pie-in-the-sky goal a bit. But within the limits of what _is_ (reasonably) practical, you should do what you _can_, not just what you think you _have_ to do.
So if using an overkill amount of salt implies also a longer and more expensive hash, that's good, because you probably should be using a longer and more expensive hash anyway, if you possibly can. I believe the OpenBSD crowd has this one right.
And as I said, the limitations of a known and respected algorithm are a fairly good reason for limitations on salt and password length, because there is significant security value in using a known and respected algorithm.
> On the other hand, even 64 bits of salt is quite paranoid anyway.
Yeah, but if 128 bits is *more* paranoid, and current hardware is capable of handling it, then it's better. The question isn't (or shouldn't be) "How paranoid is paranoid _enough_?" but rather "Exactly how paranoid can we be without creating significant usability problems?" The former question
> Pachelbel just happened to string together a melodic progression that appeals to the common fool, > which is why every other rock/pop/punk hit today is just the same dumb Canon with drums and > some interchangeable teenage angst vocalists.
Wait, you're running into rock and pop songs with a canon form? We must inhabit different universes altogether. Most of the rock and pop songs I've encountered barely even have harmony. Just about the only counterpoint I've encountered in modern music (aside from a few niche groups (like Haggard) and composers (like Shickele)) is rhondo (a much simpler and less interesting form than canon), and in my experience even rhondo is pretty rare in rock and pop.
What I really like is fugue. BWV 1080 is the stuff.
Slashdot Mirror
Oh, yeah, I forgot about turkey. Practically all Americans will eat turkey -- its acceptance level as food is at roughly the same level as chicken or pork. It isn't eaten as often, but that's due to a combination of its being more expensive most of the time and its normally being sold as a whole turkey, which is too much for a single meal for most families. (Chicken is normally sold broken down into pieces, which is more convenient on a day-to-day basis. You can also buy a whole chicken, but it's less common, not to mention much smaller than a turkey anyway.)
> Americans, who are the most sentimental people in the world when it comes to animals, eat meat
...), and a small percentage of Americans will also brave marginally less common farm animals (sheep, goat, ...).
> only through a process of denial. My sister in law was feeding her boys "Chicken Fingers", and
> the older boy mimed chopping off his fingers, saying "Thwack!, Cluck, cluck, cluck!". "Oh,
> Jeffry," the other replied, "it's not that kind of chicken."
Not all Americans are that dumb. (I suspect most would tell the boy something more along the lines of "Don't be disgusting" or perhaps "It's not that kind of fingers.") And while Americans are very sentimental about *pets*, most have no qualms at all about eating cows, chickens, or pigs.
Admittedly, if you offer an American meat from some *other* kind of animal, you're liable to get a less than enthusiastic reaction a fair percentage of the time.
At least 60% of American men (probably more) and a significant minority of American women will eat fish, though this tends to be limited to certain *types* of fish, most notably perch, catfish, salmon, tuna, whiting (the kind of fish in "fish sticks" and "Filet O Fish" and such), trout, bass, walleye, and panfish. In some regions there are additions to this list, e.g., in Michigan they eat muskellunge. Carp is also known as a food but is closely associated with a specific ethnic group; most other people won't touch it. There are a small handful of other seafood items that a significant minority of Americans will eat too, mainly shrimp and lobster, but near the coasts also crab and oyster and such.
Also a significant minority of Americans will also eat traditional "hunting" animals (rabbit, deer, squirrel,
But when you start talking about eating pretty much anything that moves, you can easily get into territory where most of the population will consider you looney. Just *suggesting* that people could eat reptiles will get you some pretty shocked looks, for instance.
Actually, the method I've heard of for dealing with obnoxious cats is to leave small pieces of sponge soaked in fish oil sitting around all the time. I've never tried it, so I can't personally verify the effectiveness.
> Given the ambiguity
IMO, the adjective "yappy" is adequate disambiguation.
> I'll grant, a rootkit could conceal itself better with root access, but I doubt very many people
.bash_profile, or the gnome-session entry, or whatever) that sets the thing running each session. But if 80% of users don't find it for over three months and 50% don't find it for over a year, the malware could build up a pretty sizeable installed base (especially in the proposed fantasy world where *nix systems (counting OS X) are 67% of the world's desktops).
> would notice an extra process running anyways. (I think I'd call my trojan "bash").
I'll go you one better: the installer can just check the current process table at install time, make a list of anything the user's running multiple copies of, pick one of them at random, and name the trojan executable that. So if the user's got three copies of Emacs running at the time the thing installs, the trojan could end up being named emacs, but on a vi user's system it would be named something else. Similarly, it could be named bash on a bash user's system, but if the user had changed his default shell to tcsh or whatnot, then the trojan would not be named bash. This tactic should help the thing blend in better on process lists and escape casual, accidental detection most of the time.
The user could potentially still discover it, e.g. by finding the cronjob (or the line in
Of course, that's in the absense of anti-malware software making a concerted effort to detect such things. Unix-like systems on the whole don't need traditional anti-virus software (in the sense of protecting against file viruses) because system permissions (assuming the user doesn't normally run as root) effectively thwart that kind of malware anyway. But trojans and other social-engineering attacks are altogether another thing. There are intrusion detection systems, of course, in just about every major distro, but I think most users of the distros in question don't really know how to use them, as they currently stand. (I only recently studied up on how to use chkrootkit and rkhunter myself, and I think there are other types of IDS that I still haven't studied up on. I first started using Linux systems in 1998...)
> Which environment would a trojan/botnet writer target and why?
They would (and do) target all of them.
That doesn't imply that they all are (or would be) equally insecure, however.
> If it's the problem of a site seeing IE8 and then running IE6 code hacks, then they could
> just rename the whole browser to something cool like Expanse 1.0 or something
I wonder about this too. If IE8's interoperable rendering is as much better as they indicate, wouldn't it be an opportune time to (finally) update the user-agent string? IE has been spoofing Mozilla for pretty much its entire history, but is that really still desirable? In the early days spoofing Mozilla meant you got the "enhanced" content intended for Netscape browsers (with, you know, cool colors and stuff). Later other browsers started to spoof the "IE spoofing Mozilla" combination, because that typically meant you got the spiffy DHTML content intended for IE5. Now most other browsers have largely _quit_ doing that, so they can get the more standards-compliant content (and here I'm using the term loosely; said content is seldom fully compliant) typically intended for Firefox. If I were the IE8 team, I'd be taking the opportunity now to update the User-Agent string.
Given that naive sniffing code typically just does a substring check, usually for "IE" and sometimes the version number, the obvious thing is to remove the string "IE" from the UA string. If it were me, I'd make it something along these lines...
Internet Explorer/8.0 (Win32; Windows NT 6.0; en-US)
Rebranded versions (notably, MSN Explorer) could throw whatever vendor indicator they like on the end of that.
Yeah, secretly, what they're really working on, is the next game in the Commander Keen series.
Apparently you are not very familiar with game vaporware history. If you were, you would have heard of Daikatana. It turns out that hyping a game for a really long time doesn't necessarily make it successful when you finally do release it. In fact, usually it just turns out to be based on obsolete technology from several years ago, when you started working on it.
> The speedier regex engine is going to be a great boon.
If you say so. My experience has been that the existing regex engine is pretty much never a performance bottleneck for anything I'm doing. (Usually when I do see perf issues it's an I/O bottleneck at fault, typically either the network or the database.)
I'm much more interested in the new features. I'm really looking forward to Perl6, but meanwhile some new features in Perl5 will be nice to have.
> So, he instead went with a thinner, workable cover and cosmetic only gears.
That's fine as far as it goes, but the cosmetic clockwork still should have been laid out in a plausible arrangement. It doesn't bother me as much as the other poster, but I did notice it.
All I want to know about upcoming XHTML versions is, can we finally put block-level elements inside paragraphs? We've been whining about the inability to do this, and basically not _using_ paragraphs as such because we can't, for over a decade. It's, as far as I'm concerned, the *one* problem with XHTML as it stands.
As far as HTML5, I thought XHTML was supposed to *be* HTML5, conceptually if not in name. Having received the benefits of well-formed markup, why would anyone ever want to go back to the old "Maybe this element is inside of that paragraph, or maybe it's after it, depending on where we decide the elided close tag belongs" way of doing things? I for one don't *EVER* want to deal with non-wellformed markup again. Make it go away.
Yeah, that could be topped. Genocide as art springs immediately to mind. Have yourself a nice big old-fashioned ethnic cleansing, and then when the international community starts whining about human rights just tell them that you're a serious artist, and that your work is deeply meaningful in ways that you wouldn't expect hoi polloi to understand.
Note: I am NOT advocating this approach. I'm only saying that it would be more incomprehensible to the masses and more senseless than genetically malapulchrated cloned life as art.
> Someone can *not* sue you for speech, as that uses the courts (a branch
> of the government) to silence you, and that is prohibited by the first amendment.
This is incorrect. Someone *can* sue you for speech, or try to at any rate. Whether they'll get anywhere depends on various stuff. For instance, if they can make a coherent argument that your speech might be considered libelous, they'll probably be able to successfully drag you through the courts, and if they can make a _convincing_ argument that your speech _is_ libelous, they can potentially win the case. Libel is not the only kind of speech that they can successfully sue you for, either. Copyright and trademark violations are another example. Fraud is another (and one you can even be prosecuted for criminally, though generally you only will be if you cost the victims something tangible).
When the first amendment says "speech" and "press", it is, in context, clearly talking chiefly about political expression, not absolutely anything that anyone could ever say or write.
> I have lost faith in humanity.
I never had faith in humanity in the first place. Humanity is fallen, unreliable. Humans will fail you.
Live environments, in addition to being red, should also have been in inverse video. In other words, test environments are bright green on a black background, and live environments are black (or possibly yellow) on a red background.
Though, not having them open at the same time would also probably be a good idea. Just in case some clown gets confused about which window is receiving keyboard input at the moment.
> My productivity has been boosted four fold (not a joke!) compared to
> when I was still developing in PHP. *And* my code is now shorter, more
> readable, more maintainable, and more secure.
Sure, but that's because Ruby is a real VHLL. You could also have achieved that effect by switching to Perl or, if you don't mind thinking in object-oriented terms about absolutely everything (and can put up with syntactically significant whitespace), Python. That doesn't answer the question about Rails.
Ballistic mosquito nets are designed to protect against not just ordinary, calmly-rational mosquitos, but also against mosquitos that are going all ballistic on you. Which they tend to do when they have you severely outnumbered, because they're afraid you won't have enough blood to go around.
You probably had the good sense to let your laundered flash drive *dry* before attempting to recover the data.
It's amazing how many people, upon realizing that they've inadvertently gotten some piece of electronics wet, immediately panic and cannot resist the urge to test *right now* whether it still works or not. Of course, that's more likely to dammage it than washing it in the first place, but they don't think about that until after they find out whether it works or not.
> I don't claim to understand this at this point, but if so, there are some
> things you can create in some places which don't get automatic copyright.
> But in that case, I guess you wouldn't get a copyright even if you tried
> to register it...
IANAL, but that matches my understanding. In the US, some examples of things that are not copyrightable include very short bits of text (on the order of a couple of words, but note that they _can_ be trademarked), photographic reproductions of two-dimensional art that is in the public domain, and lists of ingredients (it is the instructions in a recipe that are copyrightable, not the ingredients list). I don't know exactly how much this varies from country to country, but there may be some things that are copyrightable in some countries but not in others.
> I must admit I haven't used BSD since 1983! I wonder if it has gotten any better in the last 24 years?
It's gotten a good deal easier to install, I can tell you that for free.
> Outlook and Exchange is highly compelling over any other options
*Are* there other options? Off the top of my head, I don't even know of any other enterprise-class fully automated virus retrieval and installation systems.
> So 2008 is finally the year of Linux on the desktop?
That was 1998, dude. All the cool kids are using BSD on the desktop now. Where have you been?
> Changing this limitation would require fundamental changes to the underlying
> blowfish algorithm, and is hence difficult to do
Ah. That makes sense, and is a good reason. In cryptography, a known algorithm that has been examined in some depth and whose strength is considered a known quantity is almost always preferable to a new algorithm of unknown and untested strength. Of course vulnerabilities (e.g., to deliberate collision generation) are from time to time discovered even in long-established algorithms, but even then usually the dammage is of a relatively mild nature, e.g., the sort of thing that potentially cuts average compromise time in half or so, as opposed to the sort of thing that reduces it a thousand fold. With a new algorithm that has not been investigated in detail by the security community, you have no idea what weakness somebody's going to uncover next week.
> As an aside, they could have done better.
Of course. That's always the case.
> For other hashing schemes, there is no point in using more salt than the size of your password hash.
Okay, but in general, I would argue that...
> (and, per the argument of the OpenBSD crowd, you *ought* have an expensive hash)
Exactly. As I was saying, I would argue that in general it is extremely worthwhile, from a security perspective, to have a hash that's longer and more expensive than you think is actually necessary.
Among other things, weaknesses *are* discovered from time to time in the known algorithms (both the hashing algorithm itself and also other related algorithms, e.g. for encryption, which is used in conjunction with hashing), and while for established algorithms these are seldom fatal, they nevertheless sometimes result in an overall reduction in security. If you're significantly more secure in the first place than you thought you needed to be, this hurts less.
Also, backward compatability concerns occasionally result in something being used *well* past the end of its original projected lifespan, and with advances in processing power (and storage, and networking, and so forth) this has significant implications for security. If you think something will *probably* be used for ten years and *potentially* could be used for as much as thirty years, it's probably best to design it to stand up to new technology for a hundred years or so if possible. Because if it's still secure fifty years after people quit using it, that's all well and good, but if it becomes insecure *while* people are still using it, that's bad. A hundred years is overkill, of course, but overkill is *good* in this context.
That's assuming, of course, that it doesn't create serious usability problems. Trying to implement a password hashing system that will stand up for a hundred years is probably doomed to failure for this reason. With current hardware you'd probably have page swapping going on every time somebody logs in, which would be bad. So fine, you end up backing off from that pie-in-the-sky goal a bit. But within the limits of what _is_ (reasonably) practical, you should do what you _can_, not just what you think you _have_ to do.
So if using an overkill amount of salt implies also a longer and more expensive hash, that's good, because you probably should be using a longer and more expensive hash anyway, if you possibly can. I believe the OpenBSD crowd has this one right.
And as I said, the limitations of a known and respected algorithm are a fairly good reason for limitations on salt and password length, because there is significant security value in using a known and respected algorithm.
> On the other hand, even 64 bits of salt is quite paranoid anyway.
Yeah, but if 128 bits is *more* paranoid, and current hardware is capable of handling it, then it's better. The question isn't (or shouldn't be) "How paranoid is paranoid _enough_?" but rather "Exactly how paranoid can we be without creating significant usability problems?" The former question
> Pachelbel just happened to string together a melodic progression that appeals to the common fool,
> which is why every other rock/pop/punk hit today is just the same dumb Canon with drums and
> some interchangeable teenage angst vocalists.
Wait, you're running into rock and pop songs with a canon form? We must inhabit different universes altogether. Most of the rock and pop songs I've encountered barely even have harmony. Just about the only counterpoint I've encountered in modern music (aside from a few niche groups (like Haggard) and composers (like Shickele)) is rhondo (a much simpler and less interesting form than canon), and in my experience even rhondo is pretty rare in rock and pop.
What I really like is fugue. BWV 1080 is the stuff.