[x]Blackmoor Vituperative

Tuesday, 2010-02-09

Comically bad password policy

Filed under: Security — bblackmoor @ 11:09

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.

Wednesday, 2010-01-06

Encryption cracked on USB drives

Filed under: Security — bblackmoor @ 16:55

A word of warning to those of you who rely on hardware-based encrypted USB flash drives. Security firm SySS has reportedly cracked the AES 256-bit hardware-based encryption used on flash drives manufactured by Kingston, SanDisk and Verbatim.

The crack relies on a weakness so astoundingly bone-headed that it’s almost hard to believe. While the data on the drive is indeed encrypted using 256-bit crypto, there’s a huge failure in the authentication program. When the correct password is supplied by the user, the authentication program always send the same character string to the drive to decrypt the data no matter what the password used. What’s also staggering is that this character string is the same for Kingston, SanDisk and Verbatim USB flash drives.

Cracking the drives is therefore quite an easy process. The folks at SySS wrote an application that always sent the appropriate string to the drive, irrespective of the password entered, and therefore gained immediate access to all the data on the drive.

(from Encryption busted on NIST-certified Kingston, SanDisk and Verbatim USB flash drives, ZDNet)

Tuesday, 2009-12-08

Presumption of guilt: Your rights when it comes to data encryption

Filed under: Privacy,Security — bblackmoor @ 14:28

Chad Perrin has a short article on TechRepublic giving a back-of-the-napkin overview on encryption as it is viewed by the courts. It is worth checking out and clicking the relevant links.

Monday, 2009-12-07

Free public OpenID server

Filed under: Security — bblackmoor @ 19:17

I have set up a free, public OpenID provider at http://www.blackgate.net/openid/, using software from Community-ID.

Monday, 2009-11-30

Passwords need to go away

Filed under: Security — bblackmoor @ 19:54

I was just creating an account on a new web site. It has freaking ridiculous password rules.

Your password must have 2 upper case letters, 2 lower case letters, 2 numbers, 2 special characters, and be a minimum of 9 characters and a maximum of 12 characters in length.

Why don’t they just generate a random string that they’ll accept and save me the bother? It’s not like I will be able to remember this monstrosity.

When I was at… Philip Morris, I think it was… there were two systems that had complex password requirements, and they were mutually exclusive. Like, one required two numbers, and the other forbade more than one number. Something like that. So ridiculous. The whole “password” thing needs to die.

I wish more places would clue into OpenID. After exams, I think I will set up an OpenID server on mortshire.org.

Tuesday, 2009-09-08

Guns can keep computers in your luggage safe

Filed under: Security,Society,Travel — bblackmoor @ 10:43

As a computer guy and a gun owner, I thought this idea was brilliant: packing your laptop with a pistol in order to keep your laptop safe while traveling via airplane.

Of course, it is vital to know all of the rules and laws when one is transporting a firearm, on an airplane or anywhere else. So do your homework first.

Then again, gun ownership in the USA is rather like an intelligence test: if you own one (or more), and stay out of jail, you pass.

Tuesday, 2009-08-25

Ex-Pirate Bay ISP sabotaged, calls in police

Filed under: Intellectual Property,Security — bblackmoor @ 19:59

According to the site TorrentFreak:

The ISP that supplied much of The Pirate Bay’s bandwidth before cutting them off yesterday, is reporting that it has been sabotaged. Calling in experts and the police, Black Internet says the attack on them is intentional and has caused substantial damage.

This makes me sad. It certainly does not reflect well on those who would see our current cartel-controlled copyright system reformed. Why attack Black Internet? They’re a victim of these thugs just as much as The Pirate Bay.

Monday, 2009-08-24

Spam from Facebook

Filed under: Security — bblackmoor @ 14:40

An amusing anecdote from the department head of the Computer Science department of Purdue University, one of the world’s experts on network security:

Bottom line: providing Facebook any access to email addresses at all is like Roach Motel — they go in, but there is no way to get them out. And Facebook’s customer service and interfaces leave a whole lot to be desired. Coupled with other complaints people have had about viruses, spamming, questionable uses of personal images and data, changes to the privacy policy, and the lack of any useful customer service, and I really have to wonder if the organization is run by people with any clue at all.

I certainly won’t be inviting anyone else to join Facebook, and I am now recommending that no one else does, either.

(from More customer disservice—This time, Facebook, CERIAS)

Makes me glad that I do not have a Facebook account.

Tuesday, 2009-07-07

Micromanagement in the name of “security”

Filed under: Security — bblackmoor @ 10:43

I am so tired of seeing IT professionals who have to plead to have access to web sites they need to do their jobs. I am so tired of someone responsible for completing a multi-million dollar project not even able to change the screen resolution on their desktop because the people in charge of “IT security” have locked it down. And heavens forbid that you install any utility not on the “approved software” list, whether or not you actually need it to do your job.

The one thing no one seems to get, and one thing which causes many of the headaches for IT professionals, is that a skilled professional should be responsible for her tools.

When you take your car to a garage, do you demand that they use a specific brand of wrench? When an electrician comes to your house, do you demand they have a specific brand of voltmeter? Do you search their toolbox, and chastise them if they have a MP3 player or a DVD in there?

Of course you don’t.

The current way security is managed in every organization I have seen in the past 15 years is based on the flawed premise that the professional whom we trust to administer and manage multimillion dollar projects can’t be trusted to select and maintain her own workstation.

This is ridiculous.

IT professionals should not have their software selection restricted (or worse, chosen for them). IT professionals should not have their Internet access filtered or obstructed (for many IT professionals, Internet access is the #1 tool in their toolbox).

“Does she get the job done safely, legally, on time, and under budget?” That is the question that should be asked of any IT professional. That question has a yes or no answer, and it has nothing to do with web filtering or “nailing down” her workstation so she can’t install “unapproved” software.

Hold IT professionals accountable, by all means, but do not pre-emptively cripple their ability to do their jobs. You hired them to be experts: let the expert choose and care for her tools, like any other skilled expert does.

Saturday, 2009-07-04

Preventing anonymous editing on MediaWiki

Filed under: Security,The Internet — bblackmoor @ 12:02

I use MediaWiki for a few web sites (Warlords of NUM and WestGuard, for example). Unfortunately, some lowlife scum like to post spam about luxury watches or viagra or whatnot on these sites, so I need to lock them down to prevent this.

The simplest way to do this is to 1) disable anonymous editing, and 2) disable account creation by anyone other than a sysop (which is to say, me). The MediaWiki manual explains how to do this (and a great many other things), but I thought it might be help for folks if I posted just those specific instructions here, since I think this is a common request for those using MediaWiki.

Simply add the following lines to the end of LocalSettings.php with a text editor such as Notepad++ (do not use Windows Notepad — use a real text editor):

## Customized settings begin here

# Disable anonymous editing
$wgGroupPermissions[‘*’][‘edit’] = false;

# Hide user tools for anonymous (IP) visitors
$wgShowIPinHeader = false;

# Prevent new user registrations except by sysops
$wgGroupPermissions[‘*’][‘createaccount’] = false;

And that’s that. You will probably also want to add a custom “wiki.png” logo. If so, you should add the path to it, like so (you will, of course, need to upload it to your site first):

## Customized settings begin here

# Custom logo
$wgLogo = ‘http://www.mymediawikiwebsite.org/skins/mycustomskin/wiki.png’;

# Disable anonymous editing
$wgGroupPermissions[‘*’][‘edit’] = false;

# Hide user tools for anonymous (IP) visitors
$wgShowIPinHeader = false;

# Prevent new user registrations except by sysops
$wgGroupPermissions[‘*’][‘createaccount’] = false;

And there you go.

« Previous PageNext Page »