Re: The no-stdio and NO_FP_API options
Am 04.09.2014 um 17:56 schrieb Salz, Rich rs...@akamai.com: So please tell me *exactly* what you require to get the NO_FP_API support into a state that it is still acceptable for you. And please tell how and on which platform I can reproduce the problems you are seeing. Any Linux platform. ./config no-stdio -DNO_FP_API should build clean. Ok, just give me some time to examine this and to cleanup our AmiSSL SVN repository so that I can provide you more clean patches to keep these things alive. And of course its clear to me that I am the petitioner. That was clear right from the start. regards, jens -- Jens Maus, Dresden/Germany http://jens-maus.de/ (Please note a real name change effective since 5.9.2013. Former name: Jens Langner) *** Content is authentic only with digital signature *** smime.p7s Description: S/MIME cryptographic signature
RE: The no-stdio and NO_FP_API options
Thanks. There is no big rush, knowing you're working on it, and this is for after 1.0.2. Perhaps by January/Feb? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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
RE: Certificate pass phrase brute force...
There is nothing special about cracking a certificate password versus any other password. There is a lot of literature out there; a web search will easily give you enough information to be depressed. I think your biggest faulty assumption is that your users will pick truly random 10char passwords. And the second-biggest is that the other attacks on their platform (windows?) won't be more effective, anyway. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
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 ATT 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
RE: Certificate pass phrase brute force...
[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
Re: Certificate pass phrase brute force...
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 ATT 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 ATT 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
Re: Certificate pass phrase brute force...
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 ATT 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 ATT 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
Re: Certificate pass phrase brute force...
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 ATT 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 ATT 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
RE: Certificate pass phrase brute force...
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 ATT 4G LTE smartphone Original message From: Gregory Sloop gr...@sloop.netmailto:gr...@sloop.net Date:09/05/2014 1:36 PM (GMT-05:00) To: openssl-users@openssl.orgmailto: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.commailto:dpax...@me.com 208 570 9755 skype: dpaxton Click herehttps://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== to report this email as spam. This message has been scanned for malware by Websense. www.websense.com
Re: Certificate pass phrase brute force...
There is nothing special about cracking a certificate password versus any other password. There is a lot of literature out there; a web search will easily give you enough information to be depressed. I think your biggest faulty assumption is that your users will pick truly random 10char passwords. And the second-biggest is that the other attacks on their platform (windows?) won?t be more effective, anyway. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz I wasn't as clear in my initial post as I should have been. These are client _keys_ [as Michael Wojcik correctly points out, they're actually keys - sorry.] for OpenVPN to connect to the corporate network. You have to have a client certificate+key [generated by OpenSSL] and the pass-phrase given when the key was created. Pass-phrases are unique for each key. Pass phrases are created by the sys-admin [us], not the end user. I'll try to respond to several of the points in a single post. @dave: We can't limit the number of attempts at the server side, since this will be an off-line attack. They've obtained our key, and are trying to brute-force the key pass-phrase. Essentially we'd assume an attacker is trying to break the encryption on the client.key [key] so they can use it. We aren't doing separate user verification. A valid certificate+key *is* the user validation. [It's the certificate+key, as well as the password. Without control of our CA, you can't generate another certificate+key, and the password is supposed to be kept separately from the key. It's not as much separation as other two-factor systems, but it's what we've got to work with.] --- @Rich / @Micheal Since IT generates the certs, IT gets to pick the pass-phrases. @Michael: Yeah, we ask the user not to store the key on the computer, and we try to generate passwords that are less work to remember and less likely to be stored on the PC. We ask that they write it down, rather than store it on the PC. But yeah - it's an issue and we're aware of the risk. @Rich / @Micheal As for attacking the machine: That's certainly a big issue - but again, if they don't have the pass-phrase, or know to capture it, they'll only get access to the OpenVPN network when the victim is connected [which is obviously bad]. But stealing the key and using an offline attack against it is the point I'm considering at the moment - even if it's, perhaps, a Maginot Line style pointless defense. [But the point about the vulnerability of the endpoint/workstation itself is clearly a valid one.] But the speed at which passwords can be tried against the key does matter - at least in trying to use the key themselves on another system. For example: Let say I send the key to a user via email. [I don't/wouldn't do this, but consider if I did.] Someone in the channel grabs it and starts working on it. If it's computationally expensive, then it will be much slower. If it's not, then one should plan for very long keys, or reducing the value of the pass-phrase via some other means. Part of the issue is: I don't know how computationally expensive this process is. [I really know almost nothing about it.] Does that help clarify? -Greg
Re: Certificate pass phrase brute force...
If someone has the encrypted key data, they can feed that data anywhere they wish. In that case, they can feed it into processing systems that do not enforce rate-limiting. Thus, there is no way to do what Dave Paxton suggests in any case. -Kyle H On September 5, 2014 12:51:04 PM PST, flgirl799901 flgirl799...@gmail.com 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 ATT 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 ATT 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
