That's a 4 year old bug. Do you think it is fixed by now?

Been fixed for ages.

Accepting long passwords may mislead people to use passphrases, the first 8 characters of which are very vulnerable to a dictionary attack. If you're only going to consider the first 8 characters, you should make it impossible to type more than 8 characters on the entry form.

Wow. I was including the original DES CRYPT function in my BSDCan talk as a purely historical element... I guess I'll need to revise that slide now.

I don't think that RHM made mistakes often, but using only the first 8 characters of a password certainly qualifies.

that would be RHM

Oops. Corrected, thanks. I wrote "Robert Morris", then realized that was ambiguous and added "(senior)", then I thought "wait, everybody just calls Robert Morris 'rtm'"...

I'm not particularly familiar with this software but it appears to be some kind of project management software. I think the odds of someone beating an 8 character well chosen password are less than the value of the data protected by said password!

That's pretty irrelevant.

In what way is suggesting that the level of security used is probably more than sufficient for the value of the data its meant to protect irrelevant?

In what I would call "economical security", you're right, it's absolutely relevant.

However, we seem to be entering an age of "ethical security". As computers and software become more powerful and complex, people expect every system that is "secure" to be "absolutely secure", at least up to some fuzzy isomorphism inside different "security classes".

What this leads to is thinking like: "if your website offers to protect my account with a password, it should be as secure as the most secure example of password-protected systems (passwords stored as hashes, strong password requirements, and so on)."

You can see this as well in the emerging (and somewhat stagnant) market of commodity biometric security devices, such as off-the-shelf fingerprint readers. There was a lot of talk about how they could be defeated by lifting your prints, taking impressions of your hand, and so forth. Essentially, the argument was "if you're going to offer biometric security, I expect it to be on par with NSA-class biometric security".

I'm not going to make a judgment as to whether this is the right approach, or not, but I suspect it is beneficial in the long run, even if unesseccarily expensive and overkill at any one point or example.

It's irrelevant because offering people the option of entering longer passwords and then discarding everything above 8 characters is stupid no matter how secure it might be.

Ok, I agree with that. I'm sure it was a side effect of some library rather than a deliberate choice though. Not to worry, as other commenters have pointed out, this has been fixed for some time.

Fogbugz often has fairly sensitive info. All our bug reports are in it, including attached data files & snippits of source code. Often customer names are in it, and sometimes customer data files. So it does matter.

Don't know if it's still the case, but Charles Schwab had the same problem. It really increased my confidence in the safety of their website.

Worked that way in many Unix systems - e.g. HP-UX as of ten years ago.

Doesn't seem to be that important - I'd worry more about a system that would reply to 10k/s remote login requests ...