The ipmitool conundrum

Question

We have been trying to migrate to a better password management system on our server. The problem was that all this days we were using a proprietary algorithm to create a hash (a decryptable hash).

In keeping with advances in Linux, we have decided to change this to a one way hash so as to enhance security. But ipmitool does client side HMAC SHA1 match instead of letting the server do the hash match.

Is there any implementation out there that doesn't kill all logic and manage user authentication the way ipmitool does (by requesting SHA1 hash from server)?

Is there anyway we can use ipmitool without using a decryptable hash?

Your IPMI devices should be a separate network/VLAN with restricted access see for instance https://www.us-cert.gov/ncas/alerts/TA13-207A . Commonly Kerberos is considered a good and secure method of authentication. — HBruijn, Jul 16 '14 at 13:39
My assumption is that English is not your first language, so please don't take this the wrong way. It's not really clear what problem you are trying to solve and so your question is on its way to being closed. Can you edit it to describe what problem you are facing? — , Jul 24 '14 at 22:00
@kce: If there is something grammatically wrong, please go ahead and edit. If you didnt understand the question, that's OK. You can read up things on ipmitool, or you can wait for an answer. If you want to close a question just because you didnt understand it, then thats ok too. Its a sad state of affairs for StackExchange websites, but still ok. :-) — Arpith, Jul 25 '14 at 03:06
@HBrujin: Agreed most ipmitool transactions happen in a separate network/VLAN. But still the RMCP session protocol wants the BMC to store the passwords in plaintext. While we are using a reversible hash since plaintext is not acceptable, was wondering if there was any way we can store passwords on BMC using one way hash and still be able to use ipmitool. — Arpith, Jul 25 '14 at 03:12

score 3 · Accepted Answer · answered Aug 10 '14 at 04:43

Nope! The problem you cite here is a problem in the IPMI spec that is still not fixed as of this writing, though the spec is as clear as mud and couldn't be more oblique about admitting it.

You can read all about it at http://fish2.com/ipmi/remote-pw-cracking.html but I think you already know.

I can't tell what you are doing exactly, but if you want to make your application secure you shouldn't base it on IPMI. I have no idea if that is an option in your case.

The ipmitool conundrum

1 Answers1