| *** ppai has joined #openstack-swauth | 05:15 | |
| *** kaleta_ has joined #openstack-swauth | 06:00 | |
| *** onovy_ has joined #openstack-swauth | 06:05 | |
| *** onovy has quit IRC | 06:08 | |
| *** kaleta has quit IRC | 06:08 | |
| *** onovy_ is now known as onovy | 06:08 | |
| *** kaleta_ is now known as kaleta | 06:08 | |
| *** openstackstatus has joined #openstack-swauth | 08:26 | |
| *** ChanServ sets mode: +v openstackstatus | 08:26 | |
| onovy | ppai: hi. i just need to explain your patch and i'm open to merge it | 10:38 |
|---|---|---|
| onovy | peterlisak: ^ | 10:38 |
| ppai | onovy, hi | 11:14 |
| onovy | password = password.encode('utf-8') | 11:14 |
| ppai | onovy, this should explain what it intends to do: http://paste.openstack.org/show/490421/ | 11:14 |
| onovy | shouldn't be this done for password_type too? | 11:15 |
| ppai | onovy, no because password_type is not sent by the client or user | 11:15 |
| ppai | onovy, further, password_type is not passed to hmac.new | 11:20 |
| onovy | same arguments are valid or password variable | 11:23 |
| onovy | and encode is called :) | 11:23 |
| onovy | or=>for | 11:24 |
| ppai | password and msg variables are passed to hmac.new() which seems to have the bug mentioned as comment | 11:25 |
| *** ppai has quit IRC | 11:48 | |
| onovy | ah | 12:22 |
| *** ppai has joined #openstack-swauth | 16:21 | |
| ppai | onovy, around > | 16:29 |
| ppai | ? | 16:29 |
| onovy | only for few seconds | 16:29 |
| onovy | :) | 16:29 |
| ppai | onovy, oops sorry, I just saw your comment | 16:30 |
| ppai | onovy, the rationale behind not including salt in "key" is that that information is already encoded in the hashed key | 16:30 |
| onovy | hmm, but that's not reason why not keep it here :) | 16:32 |
| ppai | onovy, OTOH I completely agree with your case where stolen hashed DB will let access into the system | 16:33 |
| onovy | so why not just "raise exception" here? | 16:33 |
| onovy | and don't allow this combination? | 16:33 |
| ppai | onovy, but i don't see an alternative | 16:33 |
| onovy | this=!plaintext + swift3 | 16:34 |
| ppai | onovy, do you mean swift3 + swauth will only support plaintext ? | 16:34 |
| onovy | yep, that's alternative | 16:34 |
| onovy | because it's same secure as sending hash as key | 16:35 |
| onovy | only difference is in hybrid env, where some is using swift api and other one s3 api | 16:35 |
| onovy | someone | 16:35 |
| onovy | but if i understand it correctly, amazon must have plaintext password only now, right? | 16:36 |
| ppai | onovy, well the hash is never sent over network as key. the key is converted to HMAC signature and that is sent over to the proxy server. So this is not susceptible to main in the middle attack | 16:36 |
| onovy | yep | 16:36 |
| onovy | i know | 16:36 |
| onovy | sending=using :) | 16:36 |
| onovy | so lets compare it | 16:37 |
| onovy | 1. plaintext in DB | 16:37 |
| onovy | DB=swauth | 16:37 |
| onovy | -if DB is stolen, everybody know passwords | 16:37 |
| onovy | swift api and s3 api can be used with stolen passwords | 16:38 |
| onovy | 2. hashed pass in DB | 16:38 |
| onovy | stolen hashes can't be used with swift api | 16:38 |
| onovy | but can be used with s3 api | 16:38 |
| ppai | onovy, you're right about supporting hash as key is no more secure than plaintext. however, this will leave all existing deployments with auth_type not plaintext to miss out on using swift3 | 16:39 |
| onovy | yep, so i think we want to have hashed pass + swift3 support | 16:39 |
| onovy | because for swift api is MUCH better to use hased passwd | 16:39 |
| onovy | and for swift3 api it's same | 16:39 |
| onovy | so if someone have hybrid env, let's them use hashed password | 16:40 |
| onovy | better security for swift api, same for s3 api | 16:40 |
| onovy | right? | 16:40 |
| onovy | only security concern for me is: if someone enable hashed password, he should think "password are safe if DB is stolen" | 16:41 |
| onovy | but with swift3 it's not true. password is safe, access not :) | 16:42 |
| ppai | onovy, you're right. I don't disagree with you. All I'm saying is let the user make the choice :) | 16:42 |
| onovy | i'm just trying to summarize it | 16:43 |
| onovy | so, what about this: | 16:43 |
| onovy | 1. allow to use hashed password as credential in swift3 | 16:43 |
| onovy | 2. explain security concerns inside docs | 16:43 |
| onovy | 3. implement encrypted password - every stored passwd in DB will be encrypted with key from config | 16:44 |
| onovy | (3) => another patch of course | 16:44 |
| ppai | onovy, 1 and 2 are perfect | 16:44 |
| onovy | so only question is: should salt be inside key or not | 16:44 |
| onovy | i think it "doesn't matter" | 16:45 |
| ppai | onovy, 3 is implementable and useful but only for new passwords, existing ones will have no effect | 16:45 |
| ppai | right | 16:45 |
| onovy | but if you are using same salt for more passwords, "without salt" is better | 16:45 |
| ppai | onovy, yes | 16:46 |
| onovy | why to give anyone (enduser) salt, right? :) | 16:46 |
| onovy | and maybe that's another question: if you have "key" inside s3 client config, which is already calculated hash, why we need global salt? | 16:46 |
| ppai | the client calculates key based on salt and password | 16:47 |
| onovy | s3 official client? | 16:47 |
| onovy | or any other alternative client? | 16:48 |
| ppai | there is no official client, is there ? | 16:48 |
| onovy | (exactly i never used amazon) | 16:48 |
| ppai | for the s3 perl script I use, I have a tiny python program that gets me key from salt and password | 16:49 |
| ppai | i use that | 16:49 |
| onovy | but that's useless, you know? :) | 16:49 |
| onovy | in config you should have just key=<hash> | 16:49 |
| onovy | if i can authenticate with hash, why should i have plaintext password inside config | 16:50 |
| ppai | because password is human readable | 16:50 |
| onovy | and machine-stolenable :) | 16:50 |
| ppai | if you have an app - web or whatever, users usually enter username and password | 16:51 |
| onovy | yep, that's good point | 16:51 |
| onovy | btw: how are you dealing with keystone vs. swift3? | 16:51 |
| ppai | they dont need to know that the app has salt stored in app | 16:51 |
| ppai | that's supported, as mentioned in swift3 doc | 16:51 |
| ppai | i haven't tested it | 16:52 |
| onovy | with hashed passwords? :) | 16:52 |
| onovy | maybe we should implement it same | 16:52 |
| onovy | btw: http://aws.amazon.com/cli/ // oficial client | 16:53 |
| onovy | sorry i must go now | 16:55 |
| ppai | with keystone its more complicated | 16:55 |
| ppai | there's another helper middleware in pipeline | 16:56 |
| ppai | cool | 16:58 |
| ppai | cya :) | 16:58 |
| *** ppai has quit IRC | 17:12 | |
| *** nadeem has joined #openstack-swauth | 17:53 | |
| *** nadeem has quit IRC | 19:11 | |
| *** nadeem has joined #openstack-swauth | 19:13 | |
| *** nadeem has quit IRC | 20:15 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!