Very few attackers are going to bother with an online attempt to crack a password, except when a (broken) system provides an oracle for validating password attempts. They'll get a copy of a password verifier (such as a salted hash or something encrypted using the password) and perform an offline attack.
That's been the preferred mode since, oh, the late 1980s? Stoll describes an offline attack against the UNIX password file (this is before the "shadow" file was widely used) in The Cuckoo's Egg (1989). Generally speaking, if brute-force password cracking is a significant threat in your threat model, your remediation probably needs to include a lot more than throttling online attempts. In fact, throttling online attempts often creates worse vulnerabilities, including DoS vulnerabilities and outright breaks when deliberate throttling is combined with social engineering (forged password-rest requests and the like). Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of dave paxton Sent: Friday, 05 September, 2014 15:34 To: openssl-users@openssl.org Subject: Re: Certificate pass phrase brute force... That is easy. Just restrict the number of different passwords per day. Any account. Thus the old school brute force idea passes out the window. Most of what you are looking at it a signing issue. Basically one person does a transaction and the the other person verifies it. They do the DSA and thus they are the same person as they should be. That is the idea anyway. As far as accounts go that hold those keys then you have the few problems. Did the client get hacked or you? Who can hack the account like our recent icloud picture issue. All of this is lazy programming. It is really a matter of how certain you are of the client and how you want to make sure they are who they are. No biggie. Dave. On 9/5/2014 1:03 PM, flgirl799901 wrote: How do I unsubscribe from all of this? Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone -------- Original message -------- From: Gregory Sloop <gr...@sloop.net><mailto:gr...@sloop.net> Date:09/05/2014 1:36 PM (GMT-05:00) To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> Cc: 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 -- Dave Paxton dpax...@me.com<mailto:dpax...@me.com> 208 570 9755 skype: dpaxton 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
