Perfect. No rudeness here. Just ideas. I do think that relying on a password as a base system for the private key will be the Achilles heal of any system. Even if you allow for CAPS you will soon have systems that will try to pass these in a few million times a second. As an administrator looking for the best route to take then always allow for all of the past mistakes made by others to be taken into account. Wide open systems allow for wide open attacks.
On 9/5/2014 1:51 PM, flgirl799901 wrote: > I most certainly did NOT hack into anything. I thank you so much for > your response, but deplore your rudeness > > > Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone > > > -------- Original message -------- > From: dave paxton <dpax...@me.com> > Date:09/05/2014 3:33 PM (GMT-05:00) > To: openssl-users@openssl.org > Cc: > 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> >> Date:09/05/2014 1:36 PM (GMT-05:00) >> To: 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 > 208 570 9755 > skype: dpaxton -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton
