[Spacewalk-list] API using hashed SATELLITE_PASSWORD

[Justin Edmands]

> On May 8, 2014, at 6:21 PM, Matt Micene <matt.micene at dlt.com> wrote:
> 
> The auth.login API method returns a token that is used for all of the other API calls to determine authorization.  The token will expire after a certain amount of time.
> 
> If you are looking for a way to get and store a credential session for repeated use or other scripts / calls, I solved it by creating a local "session cache" that was checked before prompting for the password again.  I also used python getpass module which treats the input specially.
> 
> You can see what I'm talking about here on github.
> 
> https://github.com/nzwulfin/spaceclone/blob/sessions/src/spaceclone/satellite/satellite.py
> 
> That's the main generator gets called by the modules that do things to instantiate a Satellite object.
> 
> Anyhow, cached API tokens, no storage of the password in the prompt.
> 
> Cheers,
> Matt
> 
>> -----Original Message-----
>> From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-
>> bounces at redhat.com] On Behalf Of Grant Gainey
>> Sent: Thursday, May 08, 2014 6:08 PM
>> To: spacewalk-list at redhat.com
>> Subject: Re: [Spacewalk-list] API using hashed SATELLITE_PASSWORD
>> 
>> ----- Original Message -----
>>> We would like to use a hashed password with the API. Example below:
>> 
>> Your example seems to just use the API with a password like usual?
>> 
>>> 
>>> # !/usr/bin/python import xmlrpclib
>>> 
>>> SATELLITE_URL = " http://satellite.example.com/rpc/api "
>>> SATELLITE_LOGIN = "username" SATELLITE_PASSWORD = "password" client =
>>> xmlrpclib.Server (SATELLITE_URL , verbose = 0 ) key =
>>> client.auth.login (SATELLITE_LOGIN , SATELLITE_PASSWORD ) list =
>> client.user.list_users (key) for user in list :
>>> print user.get ( 'login' ) client.auth.logout (key)
>>> 
>>> 
>>> Will this cause any problems in other areas? Will it work at all?
>> 
>> What are you trying to accomplish, really?
>> 
>> If it's "tell customers that their password is never known by the SW
>> server" - well, let's see.  You could set up their accounts by asking
>> them for a password, salt+hash that string, binhex it, and use *that*
>> as their SW password.  Then, to use the API, give them a
>> script/application that asked them for their 'real' password and
>> replicated the process before talking to SW. Basically, the salthash'd
>> string *is* their pwd, from SW's POV, but SW never knows the string the
>> user remembers.
>> 
>> On the other hand, if you're trying to protect your SW admin's pwd from
>> prying eyes - well, sooner or later, *something* has to call login.
>> And whatever you call the Thing that login accepts, it needs to be
>> secure, or a nosey user of your script is still going to end up with
>> the ability to trash your SW instance :)
>> 
>> But I think maybe I'm not understanding what you're trying to do.  Can
>> you give us more context?
>> 
>> G
>> 
>>> 
>>> _______________________________________________
>>> Spacewalk-list mailing list
>>> Spacewalk-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>> 
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
> 
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
Grant,
I copy pasted that from red hat docs. I was just using it as an example to avoid people picking at my specific stuff. Irony I suppose. Either way, I am using https. 

Matt, you answered my question. It looks like I'll give that a try.

If all else fails, security by obscurity I suppose :/