[x]Blackmoor Vituperative

Tuesday, 2011-08-16

“Complex” passwords are not more secure

Filed under: Security — bblackmoor @ 10:03

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.

password strength

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

Monday, 2011-06-20

Security cheat sheets from Veracode

Filed under: Programming,Security — bblackmoor @ 09:26

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.

Saturday, 2011-06-04

Passwords are useless

Filed under: Security — bblackmoor @ 11:47
ighashgpu

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.

Saturday, 2011-03-05

Body armor and ammunition

Filed under: Firearms,Security,Technology — bblackmoor @ 13:40

A friend showed me this graphic at Simple Survival Skills, showing the protection afforded by these different types of protective vests. I thought it was interesting.
Body armor categories

Here is another chart, from Body Armor News.

Ballistic chart

Ammunition From The Chart

1. .22 Magnum 40 gr. JHP (1209 FPS / 369 MPS)
2. .32 ACP 60 gr. Silvertip JHP (936 FPS / 285 MPS)
3. .380 ACP 95 gr. FMC (902 FPS / 275 MPS)
4. .38 Special 125 gr. Nyclad SWHP (1009 FPS / 308 MPS)
5. .38 Special +P 110 gr. JHP (1049 FPS / 320 MPS)
6. .38 Special +P 140 gr. JHP (869 FPS / 265 MPS)
7. 9mm 124 gr. FMC (1173 FPS / 358 MPS)*
8. 9mm 125 gr. JSP (1121 FPS / 342 MPS)
9. 9mm 147 gr. Black Talon (1010 FPS / 308 MPS)
10. 9mm 147 gr. Golden Saber (1083 FPS / 330 MPS)
11. 9mm 147 gr. Hydra Shok (1011 FPS / 308 MPS)
12. .357 Magnum 158 gr. JSP (1308 FPS / 399 MPS)
13. .357 Magnum 110 gr. JHP (1292 FPS / 394 MPS)
14. .357 Magnum 125 gr. JHP (1335 FPS / 407 MPS)
15. .40 Caliber 180 gr. FMJTC (992 FPS / 302 MPS)
16. .40 Caliber 170 gr. FMJTC (1095 FPS / 334 MPS)
17. 10mm 155 gr. FMJTC (1024 FPS / 312 MPS)
18. 10mm 170 gr. JHP (1137 FPS / 347 MPS)
19. .41 Magnum 210 gr. LSWC (1141 FPS / 348 MPS)
20. .44 Magnum 240 gr. LFP (1017 FPS / 310 MPS)
21. .45 Long Colt 250 gr. LRN (778 FPS / 237 MPS)
22. .45 ACP 230 gr. FMJ (826 FPS / 252 MPS)
23. 12 Ga. 00 Buck (9 pellet) (1063 FPS / 324 MPS)
24. 9mm 124 gr. FMJ (1215 FPS / 370 MPS)*
25. 9mm 115 gr. Silvertip JHP (1252 FPS / 382 MPS)
26. 9mm 124 gr. Starfire JHP (1174 FPS / 358 MPS)*
27. .357 Magnum 158 gr. JSP (1453 FPS / 443 MPS)*
28. .357 Magnum 145 gr. Silvertip JHP (1371 FPS / 418 MPS)
29. .357 Magnum 125 gr. JHP (1428 FPS / 435 MPS)
30. 10mm 175 gr. Silvertip JHP (1246 FPS / 380 MPS)
31. .41 Magnum 210 gr. JSP (1322 FPS / 403 MPS)
32. .44 Magnum 240 gr. SJHP (1270 FPS / 387 MPS)
33. 9mm 124 gr. FMJ (1440 FPS / 439 MPS)*
34. 9mm 115 gr. FMJ Israeli (1499 FPS / 457 MPS)
35. 9mm 123 gr. FMJ Geco (1372 FPS / 418 MPS)
36. 9mm 124 gr. FMJ Cavin (1259 FPS / 384 MPS)
37. .44 Magnum 240 gr. LSWC (1448 FPS / 441 MPS)*
38. .44 Magnum 240 gr. HSP (1320 FPS / 402 MPS)
39. 12 ga. 1 oz. Rifled Slug (1290 FPS / 393 MPS)
40. 12 ga. 1 oz. Rifled Slug (1254 FPS / 382 MPS)

Bullet Abbreviations

The following standard abbreviations are used to designate types of bullets or projectiles contained in the rounds tested.

FMC/J Full Metal Case/ Full metal Jacket
FMJTC Full Metal Jacket Truncated Cone
HSP Hollow Soft Point
LRB Lead Round Ball
LRN Lead Round Nose
LSWC Lead Semi-Wadcutter
JHP Jacketed Hollow Point
JSP Jacketed Soft Point
LFP Lead Flat Point
SJHP Semi-Jacketed Hollow Point
SWHP Semi-Wadcutter Hollow Point

Wednesday, 2011-02-23

Avast 6

Filed under: Security — bblackmoor @ 14:44

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.

Tuesday, 2011-02-01

Privacy is security: secrecy is not

Filed under: Privacy,Security — bblackmoor @ 12:24

This article is worth reading. Most people have no clue about what “security” really means, including most of the people vilifying — or praising — WikiLeaks.

As becomes increasingly obvious with the passage of time, and with the advancement of digital communication (and thus copying) technologies, privacy is security, and secrecy is not.

[…]

Perhaps the most amazing thing about all this noise over the matter is that WikiLeaks is such a vulnerable, unreliable avenue for distributing such leaks. The US government’s campaign targeting WikiLeaks in an attempt to shut it down does not only betray the culture of secrecy in government to the public at large, undermining any claims to value transparency; it also showcases the simple fact that government officials just do not get it. WikiLeaks is not the cause of the “problem” for secretive government officials. It is merely a superficial indicator of much deeper problems — of a deeply flawed security model.

(from The difference between secrecy and privacy as security concepts, TechRepublic)

Thursday, 2010-03-11

A Closer Look at the PCI Compliance and Encryption Requirements of Nevada’s Security of Personal Information Law

Filed under: Privacy,Security — bblackmoor @ 17:52

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.

Thursday, 2010-02-11

Six easy steps to a more secure Linux server

Filed under: Linux,Security — bblackmoor @ 14:44

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)

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)

Next Page »