Do you see any future to the 8-bit MCU's?

I've been using eternal-september.org for the last couple of years. Free and the only real issue I've noticed is they don't carry binary groups, but that isn't a problem at all for me.

Those kind of precautions always strike me as counter-productive. One case in point was a former credit card provider who had all that kind of strong-password precautions, expired them every 90 days and locked your account on the third unsuccessful attempt. The problem is that I may have only wanted to check my credit card online a couple of times a year at most. In other words, I needed to change my password every time I logged in.

At that point I couldn't reuse an old password since thay were automatically black-listed (in other words, they were _not_ being irretrievably hashed) so the only practical portion was to record the password somewhere - surely counter-productive. I think this kind of paranoid and truly impractical security has more to do with the card provider covering their own back than actually providing effective security.

Another case in point was in a former government job. 90%+ of the material was only restricted but there was a small minority of confidential material. In other words, not terribly sensitive stuff, but the government tends to be pretty hot on these things. Again, passwords expired every 90 days and the accounts were locked on the third unsuccessful attack. This time passwords were machine-generated. To give you some idea of how secure this "highly secure" system is in reality I once had to check everyone's desks at the end of the day for some missing papers. I checked twelve desks and found passwords for nine accounts, hidden under keyboards or suchlike. In other words, the real level of security was close to zero, since one thing those systems had going for them was a proper single-point sign on. Once logged in, you had full access to _all_ services you were authorised for.

Automated systems for enforcing these sorts of policies are silly. All they effectively do is force you to come up with (trivial) ways to get around their rules. E.g., change your "foo!Baz3" password to "goo@Caz4"... then "hoo#Daz5", etc. I.e., all you are doing is making my life more difficult and doing nothing to increase the security *on* my account.

I avoid most on-line accounts and insist on talking to a real human being. They verify the number I am calling from coincides with the number from which I originally authorized the card. And, can ask me selective questions to verify my identity -- hopefully better than a machine can!

Exactly! Remember that their goal in all of this is to reduce

sex, passw0rd, admin, god, etc. I am amazed at how often these passwords actually *work*!

The problem with passwords is that they require too much effort and discretion on the part of the user (password holder). I'd much prefer smartcard readers or their ilk... something where I can carry a *token* for authentication.

I've settled on long passwords that are easy to remember but contain unusual characters (not obvious ones like using '@' as "at", '2' as "to", '4' as "for", etc.). I also regularly watch the rainbow table builders to see what limitations they impose on their tables to block that (easy!) attack (at least on my PC's).

I routinely discard on-line accounts (email, etc.) so the problem of changing passwords seldom presents itself.

While it may indicate that, the way it's usually done is to keep the last N hashes, and prevent password that have the same hash from being reused. Obviously there's a chance of collisions, but a decent hash of adequate size keeps that to a minimum.

A problem with the one-way hashes is that they inherently reduce the entropy in the passwords, since you're throwing some of that away to make the process irreversible. So there will always be multiple passwords that hash to the same value.

Not here, since the blacklisting was coupled with a "too much alike" test. So, for example, if a previous password was "Password1" it would reject "Password2" as well. I don't see how you can implement that without being able to recover the original password.

Usually you do a number of very short "hashes" to catch certain conditions. For example, you could sum the characters of the password (perhaps mod some value), and insist that the old and new sum be at least two different - that way you catch all the password1, password2, password3... attempts. You have to be careful to not end up storing too much information when you do that. Of course that can generate false positives.

As I said, I don't know anything about the implementation in question, and they could very well be doing it badly.