[ILUG] SSH dictionary attacks.

[Badger]

On Thu, Aug 24, 2006 at 02:39:23PM +0100, Aine Douglas wrote:
> On 8/24/06, Nick Murtagh <nickm at go2.ie> wrote:
> >Colm MacCarthaigh wrote:
> >> Why wouldn't openssl be able to do it?
> >
> >That's what I was wondering. Is there someway for ROS to detect that the
> >pkcs12 file has been altered (eg a using a MAC - there is some reference
> >to this in the openssl pkcs12 man page)?
> 
> A pkcs12 file in microsoft windows gets opened by internet explorers
> certificate management system, and therefore it is important that the
> password you use on a pkcs12 file isn't actually the password, thus
> eliminating the potential security problem of someone importing a
> legal signing key into a weak key management store.
> 
> The password you set on your ROS cert is XOR'd and the last bit
> flipped, and thats the actual password for the file. Or at least it
> was in the baltimore implementation, haven't verified it since Lan
> communications re-engineered the system.
> 
> So your ROS java applet does that operation on the password you enter
> before applying the password to the security libraries, and similarly,
> if you change the password, once your password passes the policy
> requirements, it is xor'd and the last bit flipped and applied to your
> P12 file, and a copy of the cleartext password sent back to the ROS
> system over PKIK communication where it is archived for customer
> support reasons.
> 
> And just to clear it up, I don't work for Revenue / Ros / Accenture /
> Baltimore / Lan communication and have no association with any of the
> above nor have I ever had... the above was found through decompilation
> of their applet, and refactoring the code obfucation.
> 

I'm not sure that I fully understand your description of the
ROS service. For instance, when you say the user's password is
XOR'd, what exactly is it XOR'd with? Also, could you clarify
if there are two passwords in operation: one for the private
key, and one for the keystore (the pkcs12 file).

Despite my lack of understanding, it appears to me that the
ROS service you have described has very little in common with
an SSH session. In fact, the two are fundamentally different.

The reason that the ROS can control policy with respect to
key passwords is that the user is running ROS's client. This
java client, which you download from their site, can apply
policy in any manner that it wants. The whole PKCS#12 thing
is incidental. In fact, there's really no need for them to
store the private key on the user's disk at all - they could
have stored them in some encrypted form on their own servers
in a similar vein to what Hush Communications do with HushMail.

The actually service carried out by ROS occurs over a closed
protocol. I imagine that if you could reverse engineer your own
client that could communicate with the ROS server using that
protocol then you could store the private key in plaintext if
you wanted.

An SSH session uses an open standards protocol which allows any
complient client to communicate with any complient server. In
this circumstance, it is simply beyond the powers of the server
to dicate how the client will manage it's keys.

> So... if you want to manage users passwords for certificate files, you
> need to wrap with something like that which uses software traps to
> archive passwords etc if necessary. Its really what PKI is all about,
> scnearios and policies and mitigating the risks. The joys of
> opensource software is that this can easily be implemented in an
> organisation without having to invest heavily in employing a large PKI
> implementor!
> 

Hmm! PKI == kludge