[ILUG] SSH dictionary attacks.
paul at clubi.ie
paul at clubi.ie
Wed Aug 23 21:59:48 IST 2006
On Wed, 23 Aug 2006, Aine Douglas wrote:
> Paul is very correct to a certain extent....
Certain extent only? Sheesh, you must be new here.
> the more convoluted you make security the weaker the holes that are
> left in it.
And harder to find.
> You can actually control the pasphrases used to protect keys if you
> issue the keys from a corporate controlled CA,
No you can't, not for ssh keys in the actual "SSH key" sense!
You might be able to issue secret keys to users with 'good'
pass-phrases on them, but the user has full power over the key,
including power to change that annoying IT-issued pass-phrase to
something they can remember a bit easier.
> which is where I was at right back at the start of the thread when
> I queried support in SSH clients for PKCS12 keystores.
The whole smart-card world is a huge PITA, full of vendors with such
incredibly secure smartcards they can't actually tell you how to
interoperate with them, instead you /must/ use their incredible
"smartcard server" product ($$$) or their libraries.
They do usually seem to provide PAM modules for free though.
There are a good few vendors out there, google. (Authenex, RSA
Security, Secure Computing, etc..). Good luck.
> the post-it on them. Its like the oldest problem with bankcard pins.
Authentication is an old problem? Who'd have thought it...
> Even in Pauls scenario of making secure password policies and having
> them centrally enforced, try issuing to a non techie dept and give it
> a month and check the back of peoples keyboards.... bingo....
The problem here usually is that the password is protecting the
/company/ (or organisation) but not protecting anything of any value
to the user.
So you need to give the user an incentive to "care" personally about
the password, e.g. because in addition to granting access to
information sensitive to the company that password (or whatever
secret) also grants access to /personally/ sensitive information
(e.g. their email, compensation and other HR information, reviews,
One huge No-No: Do *NOT* require that each user has to know dozens of
passwords to do their job. This definitely leads to
Another huge factor is training.
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
printk(KERN_DEBUG "%s: burped during tx load.\n", dev->name)
More information about the ILUG