je comprends pas ce qu'il se passe Le 5 sept. 2014 22:04, "dave paxton" <dpax...@me.com> a écrit :
> 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> <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> <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 Paxtondpaxton@me.com208 570 9755 > skype: dpaxton > > > -- > Dave Paxtondpaxton@me.com208 570 9755 > skype: dpaxton > >
