[Apologies for top-posting; I'm using Outlook, and it's incapable of handling 
replies to HTML email properly. I'm sympathetic to its dislike of HTML email, 
but not to its inability to do things that BSD Mail managed to accomplish 30 
years ago. Anyway...]

First: Passphrases for certificates are of questionable utility. Passphrases 
for *private keys* are what most people want. A certificate is published 
information.

Second: A 10-character passphrase drawn from an even random distribution of a 
52-character alphabet is a near-mythical beast few will ever encounter. I don't 
see any advantage in incorporating it into your threat model, unless you're 
going to generate such passwords and force your users to use them. (And in that 
case they'll almost certainly record them somewhere, quite possibly in 
computer-readable form.)


Password-cracking systems are successful for one or more of the following three 
reasons:

- Users choose weak passwords. They choose natural-language words or 
predictable variations of them. They choose passwords that are too short. They 
choose passwords that are common and/or obvious (such as "asdf"). And so on.

- Password-based security systems are often broken. There's a rich history and 
literature on the subject, so I won't bother going into details. This can 
certainly include passphrases applied to private keys (or certificates), when 
there are vulnerabilities in the mechanisms provided for managing and using 
those passphrases. There isn't a lot you can do if the user has installed 
malware that includes a keylogger, for example.

- Technological advances have made password cracking significantly easier than 
it was when password-based authentication first started to be widely used. 
Hash-generation speed (as with the Elcomsoft system you mentioned) is NOT the 
most important of these. It's easy to obtain, store, and process large 
dictionaries of known passwords. It's feasible to get and use large clusters of 
systems for dictionary attacks. It's feasible to use rainbow tables. And so on.

But really the first two points are the downfall of most password-based 
authentication. Throwing technology at the problem helps, but not nearly as 
much as poor user practice and poor system design and implementation.


When a user's credentials are compromised, it will almost certainly be because 
they did something wrong, or an application developer did something wrong, or a 
system administrator did something wrong.


I'm not in the business of issuing certificates and keys myself, so I don't 
have any policies to share, I'm afraid.

Michael Wojcik
Technology Specialist, Micro Focus


From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Gregory Sloop
Sent: Friday, 05 September, 2014 13:37
To: openssl-users@openssl.org
Subject: Certificate pass phrase brute force...

General question:

I've done a number of searches and can't find a lot about the subject. [I've 
searched the list archives too...at least as best I could.]

In several cases, the most obvious being OpenVPN, I use client certificates 
generated by openssl, with a pass-phrase [password]. This means that if I ever 
have someone misplace the certificate, it can't be used without the password. 
[And I have little control about what users do with such things - they download 
and install software they shouldn't; They have unknown users use their 
machines; They get their machines/phones/tablets stolen etc.]

However, if someone loses control of the certificate, I need to consider the 
safety of the certificate. [And I have to assume I'll never know they lost 
control of it either.] Assume users are practicing reasonable security and it's 
unlikely an attacker will obtain the pass-phrase when they obtain the 
certificate. [A hard/bad thing to assume, I realize.]

So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a second 
against a certificate file. Let's assume two orders of magnitude better 
performance for a fairly determined attacker, and we're at 600K passwords per 
second. Three gets us 6M a second.

But even at 6M a sec, a non dictionary guessable pass-phrase of 10 characters 
will require ~380 years to break - which isn't too bad, IMO.  [Assume a 52 
character set. This obviously gets complicated since the pass-phase probably 
isn't completely random etc...but lets assume a theoretical 52 character random 
set.]

But since I can't find any reputable source for this kind of data, I'm 
questioning the assumptions above.

Can anyone give me some pointers at a reputable attempt at quantifying this? 
[The brute-force-ability and the speed at which it might be accomplished.]
Does anyone have a policy about loss of certificates and 
regeneration/revocation along with the underlying reasoning they're willing to 
share?

Or, perhaps I completely misunderstand what's going on, and I'd be glad to be 
corrected. [Gently is always nice.]

TIA
-Greg






Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report 
this email as spam.


This message has been scanned for malware by Websense. www.websense.com

Reply via email to