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
