Blackmoor Vituperative

The consensus among security researchers has been consistent for about 15 years: forcing password expiration based on nothing but the date makes passwords less secure.

https://www.sans.org/blog/time-for-password-expiration-to-die/

Also relevant…

I think passwords are the “rotary telephones” of this century. They will have to go away, as soon as someone (probably in Europe, for various reasons) invents something better and then it gets adopted by several large companies and/or countries. But until then… long passwords, 2FA, and trying to get out-of-date security policies to be updated (obsolete policies such as requiring passwords to “expire”, which DECADES of security research have demonstrated make passwords less secure).

Cyber-security firm CyberArk has released today a new free tool that can detect “shadow administrator accounts” inside cloud environments like Amazon Web Services (AWS) and Microsoft Azure.

https://www.zdnet.com/article/new-tool-detects-shadow-admin-accounts-in-aws-and-azure-environments/?ftag=TRE-03-10aaa6b&bhid=71893585&mid=12954240&cid=716959071

I have been saying for years that passwords, as a concept, need to go away. As implemented, passwords don’t work, and the ludicrous “complexity” requirements imposed my many companies are little more than a guarantee that the user will write their password down, which is one of the easiest ways for a system to be compromised.

Here’s a cartoon from xkcd that illustrates why ridiculous password policies don’t even make sense from a security perspective.

The gist of it is this: long passwords (passphrases, actually) are more secure than short ones.

I ran across a set of tutorials and cheat sheets for a few of the more common security vulnerabilities this morning. I thought other people might find them useful. They’re from a company called Veracode. The guides are free, and they point to other free resources if you want to learn more, so they seem to be a pretty good starting point if you are interested in this sort of thing.

• SQL Injection
• Cross Site Scripting
• Cross Site Request Forgery
• LDAP Injection
• Mobile Code Security

I have believed for a long while now that passwords need to go away. Further support for that position is provided by a PC Pro article called How a cheap graphics card could crack your password in under a second:

Now, I cannot imagine anyone managing to mandate a nine-character, mixed-case, random-character password on an organisation. But if you did, and you weren’t hanging from a tree by the end of the first working day, the CPU would take 43 years versus 48 days for the GPU.

He then went on to add in mixed symbols to create “F6&B is” (there is a space in there). CPU will take 75 days, GPU will take 7 hours.

What does this tell us? well, the stark reality is that even long and complex passwords are now toast. If you think you were being wise by forcing users to have randomisation in their passwords, then think again. It is utterly futile.

[…]

A GPU of the type used by this chap is not unusual or high end. It is standard-issue stuff. Indeed, I have just sat through the AMD presentation here at Computex in Taiwan, and they made a big deal about putting GPU power into netbooks offering 500Gflops, without denting its 12-hour battery life. And that’s shipping within months.

All I can say is this: you have been warned. It is time to think long and hard about password security, and how you do your authentication. This has crept up on us in the background, and we really haven’t been paying attention.

Some of us have been paying attention.

Avast has come out with a new version of their antivirus and security software. I use Avast antivirus, and I recommend it to everyone. CNet has a review.

In this blog post on infolawgroup.com, David Navetta takes a closer look at the PCI and encryption requirements of Nevada’s Security of Personal Information law, including the interplay between the PCI and encryption requirements, the scope of the obligations, potential problems/ambiguities in the law, and the applicability of a “safe harbor” for security breaches.

The actual title of the article is “Six easy steps to make a super secure Linux server”, but I think that’s hyperbole. Even so, these are some basic steps that should be followed, and they do help make a server more secure.

1. Install latest security updates.
2. Disable root login via SSH
3. Disable or filter extra services
4. Remove active guest accounts and test accounts
5. Remove version notification
6. Hide application errors and PHP errors

(From Six easy steps to make a super secure Linux server, Technicant)

I have believed for a long while now that passwords need to go away. I have to wonder if this comically bad password policy is someone working within the system to get rid of them by making them even more absurd than they already are….

In “How does bad password policy like this even happen?” we addressed the deep question of what goes through someone’s head when he or she creates password policy that makes little or no sense and substantially damages security. The case in point was that of Nelnet, which had a comically bad password policy with restrictions that make no reasonable sense at all. For instance:

It can’t contain two separated numbers (i.e., Abc12ef34 would be invalid)

Perhaps the developers are deathly afraid that someone will have 4+7 in a password and somehow cause SQL to do something dangerous with it. If the database is so brittle as to be incapable of handling something like that, even when special characters such as plus signs are disallowed anyway (another golden example of bad policy at the same site), we can be reasonably certain that the offending organization should not be trusted with any private data anyway.

What can be worse than such ludicrous password policy?

How about a slightly less ludicrous policy that is almost as bad for security and comes with a completely absurd, even insane, explanation for why the password policy is so bad?

This is the case of American Express, evidently. A customer received a thoroughly crazy customer service email explaining the reasoning behind a password policy limited to eight characters, with special characters prohibited. The most unbelievable thing about this entire situation is that the email reads like it was written by a Nigerian scammer, but it came from the American Express “Email Servicing Team.”

Key phrases illustrating the lunacy of the explanation include:

• We discourage the use of special characters because hacking softwares can recognize them very easily. Presumably, this is meant to refer to keyloggers that might harvest passwords, but the fact of the matter is that detecting passwords is not dependent on the characters used. Key factors such as words (or non-word strings of characters) appearing out of context in the middle of other logged keypresses and time delays at either end of a single, relative short string of characters are much more important for identifying passwords than whether an asterisk is typed.
• The length of the password is limited to 8 characters to reduce keyboard contact. Some softwares can decipher a password based on the information of “most common keys pressed.” For commonality of keypresses to be used to statistically identify passwords, your passwords will have to be incredibly long. Otherwise, every time you type Xerox, the date or time, or an emoticon, someone trying to parse a keypress log is going to have to check to see if it is a password. Sorry — this part of the explanation is even less reasonable than the first quote.

This little gem of an email from Saturday has already spread like wildfire amongst online communities populated by people with an inkling of what “security” means, and the consensus is that whoever this person is, he or she does not not know what “security” is. One can only hope that this person is making things up to BS a customer, rather than actually expressing official American Express “security” policy.

The alternative is too horrible to imagine.