*** mancdaz has quit IRC | 00:00 | |
*** ctracey has quit IRC | 00:00 | |
*** spotz has quit IRC | 00:00 | |
*** waj334 has quit IRC | 00:01 | |
*** dstanek has quit IRC | 00:01 | |
*** comstud has quit IRC | 00:01 | |
*** mjb has quit IRC | 00:01 | |
*** chris_hultin|AWA has quit IRC | 00:02 | |
*** melwitt has quit IRC | 00:02 | |
*** zeus has quit IRC | 00:02 | |
*** odyssey4me has quit IRC | 00:02 | |
*** jmccrory has quit IRC | 00:02 | |
*** waj334 has joined #openstack-keystone | 00:05 | |
*** ctracey has joined #openstack-keystone | 00:05 | |
*** mancdaz has joined #openstack-keystone | 00:07 | |
*** zeus has joined #openstack-keystone | 00:07 | |
*** chris_hultin|AWA has joined #openstack-keystone | 00:07 | |
*** mjb has joined #openstack-keystone | 00:08 | |
*** zeus is now known as Guest68724 | 00:08 | |
*** chris_hultin|AWA is now known as chris_hultin | 00:08 | |
*** melwitt has joined #openstack-keystone | 00:09 | |
*** dstanek has joined #openstack-keystone | 00:09 | |
*** ChanServ sets mode: +v dstanek | 00:09 | |
*** jmccrory has joined #openstack-keystone | 00:09 | |
*** spotz has joined #openstack-keystone | 00:09 | |
*** comstud has joined #openstack-keystone | 00:09 | |
*** melwitt is now known as Guest68076 | 00:09 | |
*** odyssey4me has joined #openstack-keystone | 00:11 | |
*** chris_hultin has quit IRC | 00:12 | |
*** Guest68076 is now known as melwitt | 00:12 | |
*** wolsen has quit IRC | 00:13 | |
*** wolsen has joined #openstack-keystone | 00:14 | |
*** darrenc has quit IRC | 00:16 | |
*** jamielennox|away is now known as jamielennox | 00:16 | |
*** darrenc has joined #openstack-keystone | 00:17 | |
*** lamt has quit IRC | 00:17 | |
*** chris_hultin|AWA has joined #openstack-keystone | 00:18 | |
*** chris_hultin|AWA is now known as chris_hultin | 00:18 | |
*** _cjones_ has quit IRC | 00:24 | |
*** _cjones_ has joined #openstack-keystone | 00:25 | |
lbragstad | dolphm we had a long talk about performance testing at the PTG, but I never captured it in the etherpad (not sure if it was out of session or not) | 00:25 |
---|---|---|
lbragstad | dolphm I remember us talking about the advantages and disadvantages of locust, and that led to defining what we need in a performance testing tool | 00:25 |
lbragstad | dolphm do you remember what those things were? | 00:25 |
lbragstad | I'm working on it here fwiw - https://etherpad.openstack.org/p/pike-ptg-keystone-testing | 00:25 |
*** _cjones_ has quit IRC | 00:30 | |
*** edmondsw has quit IRC | 00:33 | |
*** edmondsw has joined #openstack-keystone | 00:33 | |
*** dstanek has quit IRC | 00:34 | |
*** dstanek has joined #openstack-keystone | 00:34 | |
*** ChanServ sets mode: +v dstanek | 00:34 | |
*** hoangcx has joined #openstack-keystone | 00:36 | |
*** edmondsw has quit IRC | 00:38 | |
*** edmondsw has joined #openstack-keystone | 00:51 | |
*** dave-mccowan has joined #openstack-keystone | 00:55 | |
*** Guest68724 is now known as zeus` | 01:02 | |
*** zeus` is now known as zeus | 01:03 | |
*** zeus has joined #openstack-keystone | 01:03 | |
*** ravelar has quit IRC | 01:04 | |
*** martinlopes has quit IRC | 01:05 | |
*** zhugaoxiao has quit IRC | 01:06 | |
*** Administrator_ has quit IRC | 01:06 | |
*** edmondsw has quit IRC | 01:08 | |
*** guoshan has joined #openstack-keystone | 01:12 | |
*** pramodrj07 has quit IRC | 01:14 | |
*** MasterOfBugs has quit IRC | 01:14 | |
*** martinlopes has joined #openstack-keystone | 01:21 | |
*** thorst has joined #openstack-keystone | 01:26 | |
*** dave-mccowan has quit IRC | 01:30 | |
*** edmondsw has joined #openstack-keystone | 01:31 | |
openstackgerrit | Ron De Rose proposed openstack/keystone-specs master: Add API key credential https://review.openstack.org/438761 | 01:36 |
*** dave-mccowan has joined #openstack-keystone | 01:37 | |
*** namnh has joined #openstack-keystone | 01:39 | |
*** browne has quit IRC | 01:44 | |
*** gyee has quit IRC | 01:45 | |
*** adrian_otto has quit IRC | 01:51 | |
*** liujiong has joined #openstack-keystone | 01:51 | |
*** dave-mccowan has quit IRC | 01:59 | |
*** edmondsw has quit IRC | 02:00 | |
*** rderose has quit IRC | 02:01 | |
*** chris_hultin has quit IRC | 02:04 | |
*** chris_hultin|AWA has joined #openstack-keystone | 02:06 | |
*** chris_hultin|AWA is now known as chris_hultin | 02:06 | |
openstackgerrit | Merged openstack/keystone master: Exclusively use restore_padding method in unpacking fernet tokens https://review.openstack.org/438207 | 02:29 |
*** rderose has joined #openstack-keystone | 02:41 | |
*** martinlopes has quit IRC | 02:42 | |
*** thorst has quit IRC | 02:44 | |
*** thorst has joined #openstack-keystone | 02:44 | |
*** rderose has quit IRC | 02:44 | |
*** rderose has joined #openstack-keystone | 02:47 | |
*** thorst has quit IRC | 02:49 | |
*** aasthad has quit IRC | 02:52 | |
*** martinlopes has joined #openstack-keystone | 02:58 | |
*** guoshan has quit IRC | 03:09 | |
*** martinlopes has quit IRC | 03:10 | |
*** tqtran has quit IRC | 03:19 | |
*** _cjones_ has joined #openstack-keystone | 03:20 | |
*** guoshan has joined #openstack-keystone | 03:28 | |
*** ngupta has joined #openstack-keystone | 03:31 | |
*** ngupta has quit IRC | 03:31 | |
*** ngupta has joined #openstack-keystone | 03:31 | |
*** guoshan has quit IRC | 03:44 | |
*** thorst has joined #openstack-keystone | 03:45 | |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth master: Add an allow_version_hack flag to session and identity plugins. https://review.openstack.org/438788 | 03:47 |
*** thorst has quit IRC | 03:50 | |
breton | .цшт 23 | 03:51 |
breton | :( | 03:51 |
*** lucasxu has joined #openstack-keystone | 03:53 | |
*** Dinesh_Bhor has joined #openstack-keystone | 03:59 | |
*** _cjones_ has quit IRC | 04:17 | |
jamielennox | mordred, notmorgan: ^ | 04:17 |
*** _cjones_ has joined #openstack-keystone | 04:17 | |
*** ngupta has quit IRC | 04:35 | |
*** lucasxu has quit IRC | 04:54 | |
*** adriant has quit IRC | 05:30 | |
*** guoshan has joined #openstack-keystone | 05:33 | |
*** jaosorior has joined #openstack-keystone | 05:41 | |
openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Use pdkfd_sha512 instead of sha512_crypt https://review.openstack.org/438808 | 05:46 |
*** rderose has quit IRC | 05:50 | |
notmorgan | lbragstad: ^ there is the code fix, please take a look at it and the bug. | 05:51 |
*** guoshan has quit IRC | 06:03 | |
*** guoshan_ has joined #openstack-keystone | 06:03 | |
*** _cjones_ has quit IRC | 06:05 | |
*** lamt has joined #openstack-keystone | 06:26 | |
*** masuberu has quit IRC | 06:27 | |
*** abhishekk has joined #openstack-keystone | 06:29 | |
*** gk-1wm-su has joined #openstack-keystone | 06:33 | |
*** gk-1wm-su has left #openstack-keystone | 06:33 | |
*** richm has quit IRC | 06:43 | |
*** thorst has joined #openstack-keystone | 06:46 | |
*** thorst has quit IRC | 06:51 | |
*** lamt has quit IRC | 06:52 | |
*** tqtran has joined #openstack-keystone | 07:03 | |
*** tqtran has quit IRC | 07:07 | |
*** phalmos has quit IRC | 07:08 | |
*** rcernin has joined #openstack-keystone | 07:11 | |
*** zsli has joined #openstack-keystone | 07:13 | |
*** tesseract has joined #openstack-keystone | 07:34 | |
*** ctracey has quit IRC | 07:35 | |
*** ctracey has joined #openstack-keystone | 07:36 | |
*** guoshan has joined #openstack-keystone | 07:39 | |
*** dtroyer has quit IRC | 07:40 | |
*** dtroyer has joined #openstack-keystone | 07:40 | |
*** guoshan_ has quit IRC | 07:41 | |
*** h5t4 has joined #openstack-keystone | 07:47 | |
openstackgerrit | Colleen Murphy proposed openstack/keystone master: Add instruction to restart apache https://review.openstack.org/437423 | 07:55 |
*** gk-1wm-su has joined #openstack-keystone | 08:12 | |
*** gk-1wm-su has left #openstack-keystone | 08:12 | |
*** pcaruana has joined #openstack-keystone | 08:17 | |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth master: Add an allow_version_hack flag to session and identity plugins. https://review.openstack.org/438788 | 08:22 |
*** masber has joined #openstack-keystone | 08:24 | |
*** zsli has quit IRC | 08:47 | |
*** zsli has joined #openstack-keystone | 08:48 | |
*** zzzeek has quit IRC | 09:00 | |
*** zzzeek has joined #openstack-keystone | 09:12 | |
openstackgerrit | Alfredo Moralejo proposed openstack/keystone master: Remove domains *-log-* from compile_catalog https://review.openstack.org/438875 | 09:33 |
*** zsli has quit IRC | 09:36 | |
*** jaosorior has quit IRC | 09:39 | |
*** jaosorior has joined #openstack-keystone | 09:40 | |
*** lwiecek has joined #openstack-keystone | 10:00 | |
*** hoangcx has quit IRC | 10:10 | |
*** liujiong has quit IRC | 10:11 | |
openstackgerrit | Colleen Murphy proposed openstack/keystone master: Fix duplicate handling for user-specified IDs https://review.openstack.org/438896 | 10:21 |
*** guoshan has quit IRC | 10:23 | |
*** mvk has quit IRC | 10:42 | |
*** namnh has quit IRC | 10:43 | |
lwiecek | Hello. I am trying to install keystone using a ready openstack-keystone-ansible-role and the keystone gets installed, however playbook fails at step: Ensure service tenant, which is adding service tenant. After investigation, I need to do following steps manually to make it work: 1. Install correct version of pysaml2 in virtualenv (I install 3.0.2, the role installs the newest. 2. I have to make 4 spaces that are missing | 10:47 |
lwiecek | (in first line after <VirtualHost *:5000>) 3. Logs show that wsgi-module is not loaded properly. It seems that it /var/www/cgi-bin/keystone/main is executed by wrong python. I can manually fix it by entering virtualenv, sourcing keystone admin credentials and running it manually (python /var/www/cgi-bin/keystone/main). I used Ansible 2.2.1.0 (requirements specifies minimum 2.0 version). How can I fix this? | 10:47 |
*** thorst has joined #openstack-keystone | 10:48 | |
*** thorst has quit IRC | 10:53 | |
*** nicolasbock has joined #openstack-keystone | 11:09 | |
*** mvk has joined #openstack-keystone | 11:14 | |
*** richm has joined #openstack-keystone | 11:14 | |
*** ayoung has joined #openstack-keystone | 11:21 | |
*** ChanServ sets mode: +v ayoung | 11:21 | |
lbragstad | lwiecek that sounds like something the #openstack-ansible channel would be able to help with | 11:45 |
lbragstad | lwiecek they are the folks that write and maintain those playbooks | 11:45 |
lbragstad | notmorgan awesome - i'll be sure to take a look | 11:45 |
*** zeus has quit IRC | 11:52 | |
*** zeus has joined #openstack-keystone | 11:54 | |
*** zeus is now known as Guest91249 | 11:54 | |
*** ildikov has quit IRC | 12:01 | |
*** ildikov has joined #openstack-keystone | 12:03 | |
*** johnthetubaguy has quit IRC | 12:04 | |
lwiecek | ok thank You for answer. I will ask there | 12:07 |
*** fungi has quit IRC | 12:11 | |
*** johnthetubaguy has joined #openstack-keystone | 12:14 | |
*** Guest91249 has quit IRC | 12:17 | |
*** fungi has joined #openstack-keystone | 12:17 | |
dstanek | lbragstad: can't sleep? | 12:22 |
lbragstad | dstanek morning! | 12:22 |
dstanek | good morning | 12:22 |
lbragstad | dstanek i wanted to finish up summarizing the PTG, but I didn't finish it last night | 12:23 |
*** zeus- has joined #openstack-keystone | 12:24 | |
dstanek | aye | 12:27 |
breton | so in auto-provisioning | 12:27 |
breton | what role are the users supposed to have in their own prjects? | 12:28 |
breton | for example, what role userA should have in "Dev project for userA"? | 12:28 |
lbragstad | breton that's defined in the mapping, if the mapping contains a project it must also contain a role | 12:28 |
breton | lbragstad: yeah, i understand. But what should that role be? admin or member? | 12:29 |
lbragstad | breton i guess that's up to the deployment, if the deployment is already using the admin_project, then giving 'admin' might not hurt | 12:29 |
breton | does devstack use admin_project? | 12:30 |
lbragstad | https://github.com/openstack-dev/devstack/blob/7a30c7fcabac1cf28fd9baa39d05436680616aef/lib/keystone#L383 | 12:30 |
lbragstad | breton doesn't look like it - https://github.com/openstack-dev/devstack/blob/7a30c7fcabac1cf28fd9baa39d05436680616aef/lib/keystone#L343-L347 | 12:31 |
breton | also | 12:34 |
breton | what is is_admin? | 12:34 |
lbragstad | breton in the token? | 12:34 |
breton | in policy.json | 12:35 |
lbragstad | breton oh - i want to say that is and old workaround for something | 12:36 |
lbragstad | breton i'm not completely sure what | 12:36 |
lbragstad | I know we have something that take https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L124-L140 into account, but i'm not sure if that's one of them | 12:37 |
breton | looks like for admin token | 12:38 |
*** Dinesh_Bhor has quit IRC | 12:39 | |
*** zeus- is now known as zeus | 12:41 | |
*** zeus is now known as Guest83991 | 12:41 | |
*** thorst has joined #openstack-keystone | 12:47 | |
breton | so the problem today in devstack is that if i give user role admin in their own project, they can edit all flavors | 12:49 |
lbragstad | hmm - that sounds like a nova policy bug | 12:49 |
breton | i'll file a report now | 12:50 |
breton | lets see how easy it will be to fix with their new policy in code :p | 12:50 |
lbragstad | i want to say that the nova folks mentioned something about flavors and policy at the PTG - but i can't remember when/where it was | 12:50 |
dstanek | breton: they don't have an admin project concept or domain/project admin in nova? | 12:58 |
breton | dstanek: https://review.openstack.org/#/c/384148 looks like no | 13:00 |
breton | (why is gerrit giving me 502) | 13:00 |
dstanek | breton: i don't know how their stuff works, but maybe it's possible to do something like our cloud policy there | 13:02 |
*** edmondsw has joined #openstack-keystone | 13:05 | |
-openstackstatus- NOTICE: restarting gerrit to address performance problems | 13:06 | |
*** ChanServ changes topic to "restarting gerrit to address performance problems" | 13:06 | |
*** dave-mccowan has joined #openstack-keystone | 13:25 | |
-openstackstatus- NOTICE: ok gerrit is back to normal | 13:35 | |
*** ChanServ changes topic to "ok gerrit is back to normal" | 13:35 | |
*** rderose has joined #openstack-keystone | 13:36 | |
rderose | lbragstad: anything you want changed on this one: https://review.openstack.org/#/c/429912/ | 13:38 |
lbragstad | rderose nope - that looks good, stevemar's comment made sense | 13:40 |
rderose | lbragstad: cool, thx | 13:41 |
*** spilla has joined #openstack-keystone | 13:42 | |
*** ChanServ changes topic to "Meeting Agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Ocata goals: https://docs.google.com/spreadsheets/d/156q820cXcEc8Y9YWQgoc_hyOm3AZ2jtMQM3zdDhwGFU/edit?usp=sharing | Bugs that need triaging: http://bit.ly/2iJuN1h" | 13:42 | |
-openstackstatus- NOTICE: gerrit is back to normal and I don't know how to use the openstackstaus bot | 13:42 | |
lbragstad | lol | 13:42 |
lbragstad | I was wondering when our topic was going to come back ;) | 13:42 |
*** edmondsw_ has joined #openstack-keystone | 13:42 | |
*** edmonds__ has joined #openstack-keystone | 13:43 | |
*** lamt has joined #openstack-keystone | 13:45 | |
*** edmondsw has quit IRC | 13:46 | |
*** edmondsw_ has quit IRC | 13:47 | |
*** lwiecek has quit IRC | 13:48 | |
*** zhurong has joined #openstack-keystone | 13:51 | |
*** edmondsw has joined #openstack-keystone | 13:59 | |
*** edmonds__ has quit IRC | 13:59 | |
*** openstackgerrit has quit IRC | 14:03 | |
*** jaugustine has joined #openstack-keystone | 14:23 | |
*** chlong has joined #openstack-keystone | 14:31 | |
*** lamt has quit IRC | 14:37 | |
*** Guest83991 is now known as zeus | 14:42 | |
*** zeus has quit IRC | 14:42 | |
*** zeus has joined #openstack-keystone | 14:42 | |
*** ngupta has joined #openstack-keystone | 14:45 | |
*** ngupta has quit IRC | 14:45 | |
*** ngupta has joined #openstack-keystone | 14:46 | |
*** thorst is now known as thorst_afk | 14:46 | |
*** edtubill has joined #openstack-keystone | 14:46 | |
*** lamt has joined #openstack-keystone | 14:52 | |
*** ravelar has joined #openstack-keystone | 15:06 | |
*** zhurong has quit IRC | 15:10 | |
*** chlong has quit IRC | 15:11 | |
*** lucasxu has joined #openstack-keystone | 15:15 | |
*** openstackgerrit has joined #openstack-keystone | 15:18 | |
*** lamt has quit IRC | 15:27 | |
*** lamt has joined #openstack-keystone | 15:29 | |
*** davechen has quit IRC | 15:42 | |
*** davechen has joined #openstack-keystone | 15:42 | |
*** adrian_otto has joined #openstack-keystone | 15:42 | |
*** chlong has joined #openstack-keystone | 15:43 | |
*** ediardo has quit IRC | 15:44 | |
*** ediardo has joined #openstack-keystone | 15:46 | |
*** ngupta has quit IRC | 15:48 | |
*** ngupta has joined #openstack-keystone | 15:49 | |
*** h5t4 has quit IRC | 16:00 | |
*** jaosorior has quit IRC | 16:03 | |
*** rcernin has quit IRC | 16:08 | |
kukacz | hi, we need to synchronize users+credentials from external source to Keystone via API having the password sent in hashed form | 16:19 |
kukacz | can that be implemented, or does Keystone API assume the password to be clear text only? | 16:20 |
*** ngupta has quit IRC | 16:20 | |
*** ngupta has joined #openstack-keystone | 16:20 | |
knikolla | o/ | 16:23 |
*** edtubill has quit IRC | 16:30 | |
*** pcaruana has quit IRC | 16:34 | |
lbragstad | o/ | 16:35 |
dstanek | kukacz: keystone will assume clear text and will hash it again | 16:40 |
kukacz | dstanek: hmm, I'm not sure I understand. are you talking about hashing it for storage in Keystone backend? | 16:42 |
dstanek | kukacz: yes, keystone will take in passwords and then securely hash them for later use | 16:43 |
*** h5t4_ has joined #openstack-keystone | 16:43 | |
kukacz | ok, in this request I'm not interested in the form Keystone is storing it | 16:44 |
kukacz | rather I'm interested in the API communication between external source and Keystone | 16:44 |
kukacz | simply said - I won't get cleartext password from the external source | 16:44 |
kukacz | I will only get some hashed form - not defined yet, we're in a design phase | 16:45 |
dstanek | kukacz: if you pass your hash as the password for a user then keystone will assume the password is the hash | 16:45 |
dstanek | kukacz: do you want to reuse that hash in keystone? | 16:45 |
kukacz | hmm, maybe. I want the users to use their original password when interacting with OpenStack | 16:46 |
kukacz | but their password will be set by some external tool and stored in that external identity source | 16:47 |
*** aasthad has joined #openstack-keystone | 16:47 | |
kukacz | ... from which I'll only get it in some hashed form | 16:47 |
dstanek | kukacz: the only way that i know of to do that would be to stick it into the database directly and i don't think that's a good idea. there's also no guarantee that we ue the same hashing algorithms | 16:48 |
dstanek | kukacz: any reason why you don't use an external identity store so you don't have to keep a copy of the password hash in keystone? | 16:48 |
dstanek | ldap, federation, etc. | 16:49 |
kukacz | yes, federation as I understood from discussion here couple of weeks ago is not so mature in most of the clientside openstack libraries and tools | 16:50 |
kukacz | and LDAP - we got quite bad experience being so dependent on it with all OpenStack operations | 16:51 |
kukacz | anytime our LDAP was lagging, it had immediate effect on Openstack requests | 16:52 |
kukacz | so I consider getting back to sql backend | 16:53 |
kukacz | but need to resolve the synchronization | 16:53 |
*** agrebennikov has joined #openstack-keystone | 16:53 | |
*** _cjones_ has joined #openstack-keystone | 16:57 | |
*** tqtran has joined #openstack-keystone | 16:59 | |
openstackgerrit | Richard Avelar proposed openstack/keystone master: Policy in code https://review.openstack.org/435609 | 16:59 |
*** tqtran has quit IRC | 16:59 | |
openstackgerrit | Richard Avelar proposed openstack/keystone master: Policy in code (part 2) https://review.openstack.org/435751 | 17:00 |
openstackgerrit | Richard Avelar proposed openstack/keystone master: Policy in code https://review.openstack.org/435609 | 17:00 |
dstanek | kukacz: what are you synchonizing from? | 17:01 |
*** mvk has quit IRC | 17:02 | |
ravelar | ca | 17:02 |
kukacz | dstanek: the tool id not decided yet. out of my control. we're in a phase requesting the features | 17:03 |
openstackgerrit | Richard Avelar proposed openstack/keystone master: Policy in code (part 5) https://review.openstack.org/435757 | 17:04 |
kukacz | my request for cleartext password sync might be rejected | 17:04 |
*** nicolasbock has quit IRC | 17:04 | |
dstanek | kukacz: yeah, i can see what some would have a problem with it. but if it's just your provisioning tools doing the sync then you won't need to keep the real password around for long | 17:06 |
openstackgerrit | Richard Avelar proposed openstack/keystone master: Policy in code (part 4) https://review.openstack.org/435755 | 17:07 |
*** browne has joined #openstack-keystone | 17:07 | |
*** nicolasbock has joined #openstack-keystone | 17:08 | |
*** ngupta has quit IRC | 17:09 | |
kukacz | dstanek: sure, I'm starting from the most comfortable set of requirements - perhaps not best from security perspective though | 17:09 |
*** tesseract has quit IRC | 17:09 | |
*** ngupta has joined #openstack-keystone | 17:09 | |
kukacz | of course we might switch to a method when the password will be set and synchronized by some frontend tool, being forgotten as soon as the sync completes | 17:10 |
dstanek | kukacz: it also might be worth researching why your LDAP server was lagging and if you can do any sort of read-only caching | 17:10 |
kukacz | hm, yes the lagging was resolved. I was not happy with that kind of dependency from a general design point. the LDAP became one of the most critical point of our openstack backend infra | 17:12 |
kukacz | similar to openstack databases | 17:12 |
kukacz | so it seemed to me easier to care of one such dependency (openstack db) instead of two | 17:13 |
kukacz | dstanek: but the caching might be a help | 17:13 |
dstanek | kukacz: sure, that's an architecture decision. just making sure i lay out some options :-) | 17:14 |
dstanek | kukacz: and i agree about federation being something of a pain. this is something that we are hoping to make better | 17:14 |
kukacz | regarding the caching - must say I have not explored that much. is there a solution possible to sustain minutes~hours disconnected from LDAP backend? | 17:14 |
notmorgan | lbragstad: going to need to write a back-ported SQL migration for password fields in the DB being way too short | 17:15 |
notmorgan | lbragstad: expect something later today(ish) | 17:15 |
lbragstad | notmorgan awesome - thanks for the update | 17:15 |
lbragstad | notmorgan do you have a migration for master started? | 17:15 |
notmorgan | not at all. | 17:15 |
notmorgan | just saw the fails for the recent patch | 17:15 |
notmorgan | it's because the kfd hashing results in > 128char strings | 17:16 |
notmorgan | have to look into the string lengths and select an appropriate sized column next | 17:16 |
*** ngupta has quit IRC | 17:20 | |
*** ngupta has joined #openstack-keystone | 17:20 | |
*** h5t4_ has quit IRC | 17:22 | |
*** h5t4_ has joined #openstack-keystone | 17:24 | |
*** thorst_afk is now known as thorst | 17:27 | |
breton | oh wow, max's coal pizza charged me twice | 17:33 |
breton | both times $16 | 17:33 |
lbragstad | huh... | 17:34 |
* lbragstad remembers to check expenses | 17:34 | |
dstanek | kukacz: in past apps we've used an ldap server for our authentication that was a mirror of our corporate ldap. | 17:36 |
dstanek | kukacz: IT handled the sync process and we were given our own dedicated pool of ldap servers | 17:37 |
notmorgan | lbragstad: what was the reason for the password truncation code again? | 17:38 |
notmorgan | stevemar, dstanek: ^ cc | 17:38 |
notmorgan | i can't remember | 17:39 |
lbragstad | I thought it was because of sql column limits? | 17:39 |
lbragstad | but i'd have to go dig through the code again | 17:39 |
notmorgan | except.. we use a hash functoon | 17:39 |
notmorgan | it should result in the same length password data regardless | 17:39 |
notmorgan | now, with bcrypt (afaict), anything beyond the 55th character is lost due to the inability to consume that entropy | 17:39 |
notmorgan | but sha512_crypt... i though that resulted in a simple sha512 hash | 17:40 |
notmorgan | oh. | 17:41 |
notmorgan | FFS. | 17:41 |
notmorgan | its because people were complaining about slow authn | 17:41 |
dstanek | notmorgan: i think it was just helping people be lazy....i don't really remember though | 17:42 |
notmorgan | dstanek: yep. "OMG 4096 character passwords are slow to auth" | 17:43 |
*** jaugustine has quit IRC | 17:43 | |
notmorgan | it's a DOS mitigation issue | 17:43 |
notmorgan | which... makes keystone massively less secure. | 17:43 |
notmorgan | well then... | 17:43 |
notmorgan | just found the bug | 17:43 |
notmorgan | https://bugs.launchpad.net/keystone/+bug/1175906 | 17:43 |
openstack | Launchpad bug 1175906 in OpenStack Identity (keystone) "passlib: long passwords trigger long checks" [High,Fix released] - Assigned to Morgan Fainberg (mdrnstm) | 17:44 |
notmorgan | heck i even wrote code for it. | 17:44 |
dstanek | notmorgan: also https://review.openstack.org/#/c/77325/ | 17:44 |
dstanek | breton: was it that good? | 17:44 |
notmorgan | oh no dolphm did, i just submitted code to gerrit | 17:45 |
stevemar | lbragstad: dammit, i forgot about expense report | 17:45 |
breton | dstanek: yep. You were there too | 17:45 |
* notmorgan needs to do expense report. | 17:45 | |
dstanek | breton: i know. i was there twice :-) | 17:45 |
lbragstad | rderose do we have a spec or bug report for account linking? | 17:45 |
lbragstad | rderose i assume the api-key stuff is going to be dependent on that | 17:45 |
lbragstad | i haven't found a bug for it yet | 17:46 |
dstanek | lbragstad: i think they are orthogonal issues | 17:46 |
dolphm | notmorgan: bcrypt can't handle passwords > 55 chars? | 17:46 |
notmorgan | dolphm: it fails to use the entropy beyond 55 characters | 17:46 |
notmorgan | dolphm: so most systems pre-hash down to ~55 | 17:46 |
rderose | lbragstad: hmm... why | 17:46 |
notmorgan | then do the kdf | 17:46 |
lbragstad | dstanek i thought we wanted to finish decoupling authentication from user accounts before doing api keys? | 17:47 |
notmorgan | dolphm: this is resolved with scrypt. | 17:47 |
rderose | lbragstad: the data model supports account linking | 17:47 |
lbragstad | ah - we just don't have a any support for the actual linking yet | 17:47 |
rderose | lbragstad: yeah, we don't have a way to do via the api | 17:47 |
rderose | yet | 17:47 |
rderose | lbragstad: but with ravelar's patch we will | 17:48 |
kukacz | dstanek: I'm sure this can work in many scenarios. I'm maybe too conservative :-) | 17:48 |
*** ChanServ sets mode: +o lbragstad | 17:48 | |
notmorgan | dolphm: bcrypt is still a stronger hashing algo than pbkdf2 as it is easily breakable with GPGPU and ASICs, bcrypt is mostly fast-brutable with FPGAs simpley because ASICs usually do not have enough ram, scrypt is both Memory and CPU intensive (exponentially), which breaks down the FPGA advantage | 17:48 |
lbragstad | rderose but that won't be the only way to link accounts, will it? | 17:48 |
lbragstad | that will only work for federated users and local users, right? | 17:48 |
rderose | lbragstad: correct | 17:48 |
lbragstad | (what about linking accounts from LDAP to local users? we currently don't have anything in the pipe for that do we? | 17:48 |
rderose | lbragstad: I don't think you would need account link between ldap and local users | 17:49 |
notmorgan | the initial fix for the insecure hashing will be move to pbkdf2, which is better than plain sha512, significantly. In Pike we'll support bcrypt and scrypt. I'll work up a pre-hash if needed for > 55 character passphrases | 17:49 |
notmorgan | for bcrypt | 17:49 |
rderose | lbragstad: at least I can't think of a good use case for that | 17:49 |
lbragstad | whoa whoa whoa whoa whoa | 17:50 |
notmorgan | and in pike we'll default to bcrypt. | 17:50 |
lbragstad | ... what's @ | 17:50 |
* lbragstad doesn't move | 17:50 | |
notmorgan | lbragstad: Operator | 17:50 |
notmorgan | lbragstad: it means you can ban people from the channel etc | 17:50 |
lbragstad | uh oh | 17:50 |
dolphm | lbragstad: it's more like a target on your back | 17:50 |
*** ChanServ sets mode: +o notmorgan | 17:51 | |
notmorgan | <-- can do it too | 17:51 |
notmorgan | i just don't have it set to auto-op or auto-voice anymore | 17:51 |
rderose | notmorgan: ++ | 17:51 |
*** notmorgan sets mode: -o notmorgan | 17:51 | |
notmorgan | it's mostly the whole I try and hide in the mix of people in the channel | 17:52 |
* lbragstad tries pealing of the target | 17:52 | |
lbragstad | off* | 17:52 |
notmorgan | if you don't want to be opped i can fix it | 17:52 |
* notmorgan didn't set it | 17:52 | |
rderose | lbragstad: so ravelar's patch will enable account linking between federated and ldap/local user (depending on your identity backend) | 17:52 |
lbragstad | notmorgan it's all good - i expect to be in here all the time anyway :) | 17:53 |
rderose | lbragstad: and like I said, I don't think their is a need for linking local user to ldap (yet anyway) | 17:53 |
dolphm | i +O'd lbragstad, and was thinking to change myself and stevemar to +o ? | 17:53 |
lbragstad | rderose ok | 17:53 |
notmorgan | dolphm: that is typically my view | 17:53 |
lbragstad | dolphm what's the difference between those/ | 17:53 |
notmorgan | lbragstad: auto op | 17:53 |
notmorgan | vs on-demand op | 17:54 |
dolphm | lbragstad: you'll always appear as the channel op, we can act as backups and manually take op | 17:54 |
notmorgan | (+o means neededing to ask chanserv) | 17:54 |
lbragstad | aha - cool | 17:54 |
notmorgan | +O means chanserv auto sets it for you when you join | 17:54 |
* notmorgan doesn't see a need to be op all the time, it has been needed ... 2 times total? | 17:54 | |
notmorgan | it does make it easier to change the channel topic, but you could do that anyway by messaging chanserv | 17:55 |
notmorgan | since cores all have +t | 17:55 |
notmorgan | iirc | 17:55 |
notmorgan | rderose: is not registered with nickserv so i can't giv ehim the super power to change the topic | 17:56 |
rderose | notmorgan: what! | 17:56 |
rderose | notmorgan: thought I did that | 17:56 |
rderose | I'm on it | 17:56 |
notmorgan | hehe | 17:57 |
*** henrynash has joined #openstack-keystone | 17:57 | |
*** ChanServ sets mode: +v henrynash | 17:57 | |
notmorgan | also lbragstad should change the topic to remove the ocata goals... | 17:58 |
dolphm | notmorgan: davechen rderose rodrigods are missing | 17:58 |
notmorgan | dolphm: will fix that | 17:58 |
dolphm | rderose: you might be registered but not authenticated | 17:58 |
stevemar | dolphm: i'd be OK with +v TBH | 17:58 |
dolphm | stevemar: i was just following notmorgan's lead, but me too | 17:59 |
obedmr | hey folks, quick question, is keystone officially supporting Python3 or it's still under review/voting? | 17:59 |
dstanek | kukacz: i'm an engineer :-) i build stufff without regard to operations all the time. | 17:59 |
notmorgan | i just dropped +V as well :P | 17:59 |
* notmorgan likes hiding | 17:59 | |
notmorgan | dstanek: IVORY TOWER ENGINEERING! | 17:59 |
*** lbragstad changes topic to "Meeting Agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h" | 18:00 | |
dstanek | obedmr: part of what i want to do this cycle is make sure that we support python3. right now i don't know that to be the case. | 18:00 |
obedmr | dstanek: ok, got it, thanks for the clarification | 18:00 |
*** ChanServ sets mode: -o dolphm | 18:00 | |
rderose | dolphm: ah | 18:00 |
dstanek | obedmr: if you use it i'd love to hear your experience. i'm mostly worried about how we'd really deal with more that just ascii. | 18:01 |
dstanek | obedmr: if you just use ascii then you'd be all good | 18:01 |
notmorgan | dolphm: i set -O on you and doing it on steve, you both have +o still | 18:01 |
notmorgan | so you can /msg chanserv op #openstack-keystone <your nick> | 18:01 |
notmorgan | if needed | 18:01 |
obedmr | dstanek: ohh, I see, sure, I'll share the experience, thanks | 18:01 |
*** ChanServ sets mode: -o stevemar | 18:03 | |
*** ngupta has quit IRC | 18:04 | |
*** ngupta has joined #openstack-keystone | 18:05 | |
*** chlong has quit IRC | 18:06 | |
*** jaugustine has joined #openstack-keystone | 18:13 | |
*** henrynash has quit IRC | 18:14 | |
*** ngupta has quit IRC | 18:14 | |
*** ngupta has joined #openstack-keystone | 18:14 | |
*** henrynash has joined #openstack-keystone | 18:19 | |
*** ChanServ sets mode: +v henrynash | 18:19 | |
*** agrebennikov_ has joined #openstack-keystone | 18:27 | |
*** agrebennikov has quit IRC | 18:28 | |
*** agrebennikov__ has joined #openstack-keystone | 18:28 | |
*** henrynash has quit IRC | 18:29 | |
*** agrebennikov_ has quit IRC | 18:32 | |
*** agrebennikov_ has joined #openstack-keystone | 18:33 | |
*** lucasxu has quit IRC | 18:34 | |
*** agrebennikov__ has quit IRC | 18:35 | |
*** thumpba has quit IRC | 18:40 | |
openstackgerrit | Richard Avelar proposed openstack/keystone master: Extend User API to support federated attributes https://review.openstack.org/426449 | 18:43 |
*** henrynash has joined #openstack-keystone | 18:45 | |
*** ChanServ sets mode: +v henrynash | 18:45 | |
openstackgerrit | Richard Avelar proposed openstack/keystone master: Policy in code https://review.openstack.org/435609 | 18:53 |
dstanek | lbragstad: quota discussion in -dev | 19:02 |
*** henrynash has quit IRC | 19:05 | |
*** lucasxu has joined #openstack-keystone | 19:06 | |
*** lucasxu has quit IRC | 19:08 | |
*** thumpba has joined #openstack-keystone | 19:10 | |
*** thumpba has quit IRC | 19:10 | |
breton | oh well, max's pizza refunded the $16 | 19:11 |
*** henrynash has joined #openstack-keystone | 19:13 | |
*** ChanServ sets mode: +v henrynash | 19:13 | |
*** henrynash has quit IRC | 19:23 | |
*** chlong has joined #openstack-keystone | 19:25 | |
gagehugo | breton: thats good | 19:27 |
lbragstad | dstanek that makes sense to me | 19:32 |
lbragstad | dstanek does that change our stance on project/domain tags? | 19:32 |
lbragstad | dstanek we will still need those, right? | 19:32 |
lbragstad | we just won't be using them for limits | 19:32 |
*** lucasxu has joined #openstack-keystone | 19:45 | |
dstanek | amazon is killing me | 19:50 |
gagehugo | AWS S3 seems to be having issues | 19:53 |
gagehugo | lbragstad I thought the limits would need to be k/v? | 20:00 |
dolphm | gagehugo: just a bit :P | 20:00 |
lbragstad | gagehugo yep | 20:03 |
*** henrynash has joined #openstack-keystone | 20:04 | |
*** ChanServ sets mode: +v henrynash | 20:04 | |
notmorgan | uh | 20:04 |
notmorgan | rderose, lbragstad, dstanek, dolphm: so... | 20:05 |
dstanek | lbragstad: you were thinking about notmorgan's solution for code options | 20:05 |
notmorgan | if i need to change the length of a column... | 20:05 |
notmorgan | how the heck am i supposed to do that with the no-downtime upgrade thing | 20:05 |
dstanek | notmorgan: what will mysql do if you just resize as part of the expand? | 20:06 |
notmorgan | dstanek: lock the table afaik | 20:06 |
notmorgan | dstanek: and cause issues if you're actively trying to read | 20:06 |
dolphm | notmorgan: create a new column, migrate data over, drop old column? | 20:06 |
notmorgan | dolphm: ok password is going to get stupid ugly then | 20:07 |
dstanek | password_2 | 20:07 |
notmorgan | 128char is not enough space | 20:07 |
dstanek | password_second_try | 20:07 |
*** h5t4_ has quit IRC | 20:07 | |
notmorgan | dstanek: i want to just break this no-downtime-upgrade and say "sorry, this is a bad feature you're demanding" | 20:07 |
notmorgan | RDBMS does a poor job of this | 20:07 |
notmorgan | it works a lot better with the NoSQL dbs. | 20:08 |
*** belmoreira has joined #openstack-keystone | 20:08 | |
notmorgan | because at this point i am looking at a backport story that is extremely ugly and having to fix past migrations too. | 20:08 |
notmorgan | basically pbkdf2_sha512 results in a 130character hash | 20:09 |
dstanek | would you have to fix past migrations? can't use a placeholder? | 20:09 |
notmorgan | and scrypt (future looking) can be upwards of 1500 characters. | 20:09 |
notmorgan | no, can't because this is back to mitaka | 20:09 |
notmorgan | and if we "fix" mitaka and passwords are migrated (data migrations) to the new table | 20:09 |
notmorgan | it would fail if the column (old) size is > 128 | 20:09 |
notmorgan | so need to use the placeholders *and* fix old migrations | 20:10 |
dstanek | notmorgan: that's a lot of suckage | 20:12 |
notmorgan | dstanek: yep. and then add in the no-downtime upgrades and needing to tack in code for N and O for basically "password_2" column | 20:12 |
notmorgan | because changing a table definition is not "safe". | 20:13 |
dstanek | notmorgan: can you use placeholders for M, N and O - and have them know to look for the size before they resize? so basically the same migration with several different filenames | 20:13 |
*** agrebennikov_ has quit IRC | 20:13 | |
notmorgan | dstanek: it nope, since the migration M->N in migrate_repo does the data migration | 20:13 |
notmorgan | it's a lot of duplicated work and has to be in both places | 20:13 |
* notmorgan sighs. | 20:14 | |
notmorgan | the other option is we say "screw it" and don't backport the change in hashes | 20:15 |
notmorgan | and just issue an OSSN that says "sorry, this isn't being backported, we know it is insecure" because you need the values from the db to brute force it | 20:15 |
*** harlowja has quit IRC | 20:15 | |
notmorgan | it doesn't fix Pike uglyness needing multiple password columns | 20:15 |
*** harlowja has joined #openstack-keystone | 20:16 | |
notmorgan | because the db abstraction is weird. | 20:16 |
*** adrian_otto has quit IRC | 20:16 | |
* notmorgan somewhat wishes for the days of being the only one running an application so changes like this can be planned/staged in a way that doesn't need to be "universal" for a ton of various environments | 20:17 | |
notmorgan | dstanek: i just don't know what the best way forward is atm. | 20:21 |
notmorgan | dstanek: i prefer a full backport, but this might be difficult enough that it's not worth it | 20:22 |
notmorgan | ok. i 'm going to just exempt this from the restriction because 20-60seconds of delay [and no data loss, we're expanding the table] is worth it for security | 20:36 |
notmorgan | it's not like we're changing data types here. | 20:36 |
notmorgan | dstanek, rderose, dolphm: ^ | 20:36 |
*** mvk has joined #openstack-keystone | 20:37 | |
* notmorgan conversed with some MySQL experts on this before making that decision | 20:37 | |
dolphm | notmorgan: keystone will not be able to claim the zero downtime tag for the entire release, then | 20:41 |
notmorgan | dolphm: then the tag is poorly written | 20:42 |
notmorgan | it doesn't require a downtime. | 20:42 |
notmorgan | it is minimally invasive and might cause slower auth, and a short window of no user-creation | 20:42 |
dstanek | notmorgan: where did the 20-60 number come from? | 20:43 |
notmorgan | talking w/ some mysql folks | 20:43 |
notmorgan | it should be very narrow unless the password table is exceptionally large | 20:43 |
notmorgan | since it is alter column 128 length -> 256 length | 20:44 |
notmorgan | erm 255 | 20:44 |
notmorgan | it doesn't even change page utilization | 20:44 |
dolphm | notmorgan: performance degredation is allowed by the zero-downtime tag, but not by zero-impact upgrades | 20:44 |
dolphm | which is a more difficult, subsequent tag | 20:44 |
notmorgan | dolphm: for security fixes, i'd say ditch zero-impact | 20:45 |
notmorgan | in fact, i would never ever ever apply for zero-impact | 20:45 |
dolphm | but if auth fails, even due to a reasonable client-side timeout, then that's downtime | 20:45 |
*** chris_hultin is now known as chris_hultin|AWA | 20:45 | |
notmorgan | it is stupid. | 20:45 |
notmorgan | it should cause an internal copy of the db | 20:45 |
notmorgan | but not prevent reads | 20:45 |
notmorgan | since it's innodb | 20:45 |
notmorgan | dolphm: anyway i still think the whole no-downtimeupgrade with the way we're approaching is is insane. | 20:46 |
notmorgan | and poorly designed and poorly implemented | 20:46 |
notmorgan | (keystone specific) | 20:46 |
dstanek | notmorgan: in what way? | 20:46 |
rderose | notmorgan: wow, tell us how you really feel | 20:47 |
rderose | :) | 20:47 |
notmorgan | triggers to begin | 20:47 |
notmorgan | all the reasons we discussed when it was implemented | 20:47 |
dstanek | notmorgan: yeah, but that doesn't impact what you are doing | 20:47 |
notmorgan | it does if we do zero-impact | 20:47 |
notmorgan | and if dolphm is worried about auth failures and i have to do the rotating tables, it does | 20:47 |
*** lamt has quit IRC | 20:47 | |
dolphm | no project is ready to pursue zero-impact, yet | 20:48 |
*** lamt has joined #openstack-keystone | 20:48 | |
*** chris_hultin|AWA is now known as chris_hultin | 20:49 | |
notmorgan | so ... the question is do we need password.password and password.password_2_because_we_have_security_issues (<-- no real table name, but indicative of the reason we're doing this) | 20:50 |
notmorgan | if that is the case, i'm not sure i actually have the time to do a whole series of backports for this and might just punt this to an OSSN instead of OSSA | 20:51 |
notmorgan | and only fix master | 20:51 |
notmorgan | simply too much to do. | 20:51 |
notmorgan | it does mean all past releases of keystone have an insecure password hash algorithm since it's not PBKDF2/bcrypt/scrypt | 20:53 |
notmorgan | but it is no different than what we've dealt with until now | 20:53 |
dolphm | notmorgan: what bug number is this? | 20:54 |
notmorgan | oh crap. bigger issue, if we use pbkdf2 we can't write to the old location, we have to re-hash it as sha512_crypt for old keystones *wince* | 20:54 |
notmorgan | because new keystones would update the hash to something verifyable by old keystones | 20:55 |
dolphm | that's just rolling upgrades, nevermind zero-downtime | 20:55 |
notmorgan | dolphm: yep | 20:55 |
notmorgan | means sha512_crypt has to be supported for the <roll> window | 20:56 |
notmorgan | what is the roll window | 20:56 |
notmorgan | 1 cycle? | 20:56 |
dolphm | notmorgan: yes | 20:56 |
notmorgan | (for writing both sha512_crypt and bcrypt) | 20:56 |
* notmorgan sighs. | 20:56 | |
dolphm | and only during the expand and migration phases | 20:56 |
notmorgan | https://bugs.launchpad.net/keystone/+bug/1668503 and https://bugs.launchpad.net/keystone/+bug/1543048 | 20:56 |
openstack | Launchpad bug 1668503 in OpenStack Identity (keystone) pike "sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing" [High,In progress] - Assigned to Morgan Fainberg (mdrnstm) | 20:56 |
openstack | Launchpad bug 1543048 in OpenStack Identity (keystone) "support alternative password hashing in keystone" [High,In progress] - Assigned to Morgan Fainberg (mdrnstm) | 20:56 |
notmorgan | sha512_crypt is the bigger issue | 20:57 |
dolphm | err, actually, only after the migration phase and before the contract phase | 20:57 |
notmorgan | and moving to pbkdf2_sha512 is the most backportable answer | 20:57 |
notmorgan | bcrypt and scrypt cannot be backported | 20:57 |
notmorgan | continuing hashing with sha512_crypt is *really* not good, as it provides very little to next-to-zero protection for bruteforcing the hash even with 10k rounds on modern platforms | 20:58 |
notmorgan | pbkdf2 at least requires ASIC, FPGA, or GPGPU type cracking most of the time | 20:58 |
notmorgan | and bcrypt/scrypt narrow that further | 20:58 |
*** gyee has joined #openstack-keystone | 20:59 | |
dolphm | are you somehow planning to re-encrypt passwords during the upgrade? | 21:00 |
notmorgan | you cannot re-encrypt hashes | 21:00 |
dolphm | right... | 21:01 |
*** ngupta has quit IRC | 21:01 | |
notmorgan | the plan was on password change, new hashing is used | 21:01 |
notmorgan | so an operator could force all passwords to be changed. | 21:01 |
dolphm | notmorgan: i'm not sure i understand the proposal in the bug... why keep the same default as today? | 21:01 |
notmorgan | or just wait. | 21:01 |
*** ngupta has joined #openstack-keystone | 21:01 | |
*** jaugustine has quit IRC | 21:01 | |
notmorgan | so, what we need to do is going forward, hash passwords securely | 21:01 |
notmorgan | but still allow auth for users that have old passwords | 21:02 |
notmorgan | recommendation is to force a password change across the board if you use keystone for passwords | 21:02 |
notmorgan | the thought was: all updates -> new hashing, fall back on old-hash-verify as needed | 21:03 |
*** ngupta has quit IRC | 21:03 | |
*** ngupta has joined #openstack-keystone | 21:03 | |
dolphm | expand (new pbkdf2 column), no migration, no contraction. new code writes to new password column and, as applicable, nulls old password values. | 21:03 |
notmorgan | since you can tell what hash was used based on the ident ($scrypt$/$b2[ab]$/$6$) | 21:03 |
notmorgan | old keystones could not auth then | 21:04 |
notmorgan | since old keystones don't understand pbkdf2 | 21:04 |
notmorgan | or scrypt/bcrypt | 21:04 |
notmorgan | passlib is smart, but not *that* smart. it requires the user to identify the hasher used | 21:04 |
dolphm | notmorgan: so, new code writes to both columns for an entire release? | 21:04 |
notmorgan | in two different password formats | 21:05 |
notmorgan | hash-formats. | 21:05 |
notmorgan | if we support rolling upgrades | 21:05 |
notmorgan | which, i might add, is not fixing the issue at all | 21:05 |
notmorgan | since the password would still be hashed in the db insecurely | 21:05 |
notmorgan | until we stop writing it in the old-format | 21:06 |
notmorgan | and backporting new config options is mostly a no-no | 21:06 |
dolphm | notmorgan: correct, but it's fixing a long term issue in the long term | 21:06 |
notmorgan | from a security perspective, if the db is exposed, expect your passwords to be crackable from the hashes. | 21:07 |
notmorgan | with sha512_crypt | 21:07 |
dolphm | today? | 21:07 |
notmorgan | today | 21:07 |
dolphm | notmorgan: so, if i send you a sha512_crypt ciphertext, you can send me back the plaintext in the near future? | 21:08 |
notmorgan | some of the big data breaches are only realatively safe because they used bcrypt vs something less secure. | 21:08 |
*** abhishek_k has joined #openstack-keystone | 21:08 | |
notmorgan | dolphm: if i setup jack the ripper or similar tools, likely | 21:08 |
notmorgan | dolphm: sha512_crypt isn't password-based key derivation | 21:09 |
dolphm | i would say vulnerable passwords are no more vulnerable today than they were yesterday, then | 21:09 |
dolphm | sha512_crypt is not inherently broken, it's just not as secure as a more secure option | 21:09 |
dolphm | notmorgan: is that incorrect? | 21:10 |
*** abhishekk has quit IRC | 21:11 | |
notmorgan | sha512_crypt simply doesn't provide real protection | 21:11 |
dolphm | that depends on whether your password is "password" or "we4t9ogh04t6h80we", correct? | 21:11 |
notmorgan | the advantages of pbkdf hashing is that is has better resource demands on time-complexity | 21:11 |
notmorgan | dolphm: somewhat, the fact that i can hash millions-10s of millions of strings a second on my home GPU in sha512_crypt means the time-complexity is low | 21:12 |
notmorgan | dolphm: "password" would probably be caught by a rainbow table | 21:12 |
notmorgan | fwiw | 21:12 |
*** adrian_otto has joined #openstack-keystone | 21:13 | |
notmorgan | the latter password is unlikely to be rainbowtabled. | 21:13 |
dolphm | sure, but sha512_crypt still safely protects strong passwords. pbkdf2 offers much better protection for weak passwords. | 21:13 |
*** dave-mccowan has quit IRC | 21:13 | |
notmorgan | from rainbow tables. | 21:13 |
notmorgan | somewhat | 21:13 |
notmorgan | but with todays commodity (and cloud-accesible hardware) | 21:14 |
notmorgan | it isn't hard to brute force sha512_crypt | 21:14 |
notmorgan | dolphm: if you want i'll produce a demo for you showing what hashcat and similar tools can do | 21:15 |
notmorgan | it simply comes down to sha_512 is significantly less secure from modern tools than pbkdf_sha512. | 21:18 |
notmorgan | and likewise bcrypt is better than pbkdf2_sha512 | 21:18 |
*** belmoreira has quit IRC | 21:18 | |
notmorgan | s/pbkdf_sha512/pbkdf2_sha512/ | 21:18 |
notmorgan | afaict | 21:19 |
dolphm | i believe i understand the risk, and don't see a strong reason to push an emergency fix, or even bother with a backport. new release of keystone begins rolling migration to stronger algorithm, future release drops support for old algorithm entirely. | 21:19 |
*** belmoreira has joined #openstack-keystone | 21:20 | |
dolphm | everyone will be glad to see the improvement in security, certainly | 21:21 |
*** henrynash has quit IRC | 21:22 | |
*** gyee has quit IRC | 21:22 | |
*** gyee has joined #openstack-keystone | 21:23 | |
notmorgan | i'm fine with a moving forward OSSN instead of an OSSA | 21:23 |
notmorgan | just want to make sure we know the risk(s) involved | 21:23 |
dolphm | (i actually can't remember the difference between the two) | 21:24 |
dolphm | both communicate the risk... what's the difference? advisories come with backports? | 21:24 |
notmorgan | OSSA has backports | 21:25 |
notmorgan | all supported releases are fixed | 21:25 |
notmorgan | OSSN is a lot less noticable | 21:25 |
dolphm | my suggestion would be OSSN + release notes, then | 21:25 |
notmorgan | now... to be fair, sha256/512_crypt is "secure" in somuch as unix uses it in the shadow file | 21:26 |
*** henrynash has joined #openstack-keystone | 21:26 | |
*** ChanServ sets mode: +v henrynash | 21:26 | |
dstanek | notmorgan: not saying we should do this, but would it be possible to mitigate the risk with older versions using larger salts (if we had to) | 21:26 |
notmorgan | it's just that you still don't wnat your shadowfile exposed and web apps are more likely to see exposure of info than shadow | 21:26 |
dolphm | dstanek: that's an interesting idea | 21:26 |
notmorgan | you can use larger salts | 21:26 |
notmorgan | it's not a huge win in the case of sha[512|256]_cryupt | 21:27 |
*** chlong has quit IRC | 21:27 | |
dolphm | what's the default salt now? | 21:27 |
notmorgan | in the case of scrypt is makes a huge difference | 21:27 |
notmorgan | we do auto-gen salt | 21:27 |
notmorgan | which is a fixed size in passlib | 21:27 |
notmorgan | for sha..._crypt | 21:27 |
*** belmoreira has quit IRC | 21:27 | |
dstanek | notmorgan: if you increase the salt size they you'd have to do that much more hashing to find a password right? | 21:27 |
notmorgan | max salt_size is 16bytes | 21:28 |
notmorgan | in shaXXX_crypt | 21:28 |
dolphm | how big are the default salt values? | 21:28 |
dolphm | the autogenerated ones | 21:28 |
notmorgan | and i think it autofens 16bytes | 21:28 |
dolphm | i assume 16 bytes? | 21:28 |
dstanek | well that's garbage | 21:28 |
notmorgan | autogens* | 21:28 |
notmorgan | yeah | 21:28 |
notmorgan | scrypt is the only one where you can configure explicit salt-size for autogen | 21:28 |
notmorgan | up to 1024bytes | 21:28 |
dstanek | i want a 64b salt! | 21:28 |
notmorgan | the default for scrypt is also 16bytes | 21:29 |
dstanek | so a slower hash is better for hiding passwords, but worse for webapps | 21:29 |
notmorgan | but you can create a ~1500 character hash with 1024 bytes of salt with scrypt, and with ~20rounds, in python i'm seeing ~2-5s at that point on my laptop to validate the password | 21:30 |
notmorgan | yes. | 21:30 |
dstanek | you would think a faster hash with a much larger salt would be better for webapps without risking too much protection | 21:30 |
notmorgan | it's about going with a more time-complextiy algo | 21:30 |
notmorgan | like bcrypt | 21:30 |
notmorgan | or scrypt which is both time-complexity and memory-compexity | 21:30 |
notmorgan | the additional salt data isn't a huge deal | 21:31 |
notmorgan | most ASICs and FPGAs can handle it | 21:31 |
notmorgan | but when you start requiring 10s of KB+ of space or more, they fall to the side | 21:31 |
notmorgan | and GPGPU isn't great at bcrypt/scrypt [better than CPU] | 21:32 |
dstanek | the extra salt makes the average number of required caluculations higher | 21:32 |
dstanek | i'm curious if there's any research on that | 21:32 |
notmorgan | slightly higher, but since ASICs are being built for scrypt now (sigh) because of bitcoin... | 21:32 |
notmorgan | s/altcoin | 21:32 |
notmorgan | it helps a little, but not a lot. | 21:33 |
notmorgan | modern hardware is pretty impressive in comparison to 1999 and even 2009 stuff | 21:33 |
dstanek | i wonder what the break even point would be. is it still significantly faster to process a 16kb salted hash for example | 21:33 |
notmorgan | 1999 -> bcrypt introduction, 2009 -> scrypt | 21:33 |
* dolphm has to run | 21:34 | |
*** agrebennikov_ has joined #openstack-keystone | 21:34 | |
notmorgan | dstanek: oh pbkdf2 allows for variable salt_size | 21:34 |
notmorgan | as well | 21:34 |
notmorgan | with a max of 1024 similar to scrypt | 21:35 |
notmorgan | and bcrypt must have a salt of 22 characters (i'm sure there is a cryptographic reason for that) | 21:35 |
notmorgan | If specified, it must be 22 characters, drawn from the regexp range ``[./0-9A-Za-z]`` | 21:36 |
*** henrynash has quit IRC | 21:36 | |
notmorgan | or maybe because of the era of computation it was created in | 21:36 |
notmorgan | so anyway | 21:36 |
notmorgan | in short. if we increase the column size for password to 255, we can support up to ~128 bytes of salt in scrypt/pbkdf2 | 21:37 |
notmorgan | and sha512 and bcrypt | 21:37 |
notmorgan | keystone will have to write both fields. | 21:37 |
notmorgan | can't be done in a trigger | 21:37 |
notmorgan | this will be an OSSN | 21:37 |
notmorgan | and i'll add an option that will [in ... uh.. whatever post pike is] | 21:38 |
notmorgan | will be removed and we will stop writing in sha512 in the old location and no longer support new hashes in sha512 | 21:38 |
notmorgan | annnnnnd can simply be disabled (sha512) if folks do not want to utilize the insecure hash for rolling upgrades | 21:39 |
* notmorgan sighs at this whole ick | 21:39 | |
notmorgan | to think we almost used bcrypt instead to start. and this would have been a non-issue | 21:39 |
*** chris_hultin is now known as chris_hultin|AWA | 21:39 | |
*** chlong has joined #openstack-keystone | 21:39 | |
notmorgan | dstanek: i'll support pbkdf2, bcrypt, and scrypt as "new" hash forms and we'll default to bcrypt simply because that is the industry standard. | 21:40 |
*** thorst has quit IRC | 21:41 | |
*** thorst has joined #openstack-keystone | 21:42 | |
*** thorst has quit IRC | 21:46 | |
*** lucasxu has quit IRC | 21:46 | |
*** lucasxu has joined #openstack-keystone | 21:49 | |
*** ngupta has quit IRC | 21:55 | |
*** ngupta has joined #openstack-keystone | 21:55 | |
*** chlong has quit IRC | 21:58 | |
*** spilla has quit IRC | 22:07 | |
*** edmondsw has quit IRC | 22:17 | |
*** henrynash has joined #openstack-keystone | 22:18 | |
*** ChanServ sets mode: +v henrynash | 22:18 | |
*** henrynash has quit IRC | 22:20 | |
*** adriant has joined #openstack-keystone | 22:21 | |
openstackgerrit | Lance Bragstad proposed openstack/keystone-specs master: Remove microversions spec from backlog https://review.openstack.org/439190 | 22:22 |
*** henrynash has joined #openstack-keystone | 22:23 | |
*** ChanServ sets mode: +v henrynash | 22:23 | |
*** henrynash has quit IRC | 22:24 | |
*** ngupta has quit IRC | 22:25 | |
*** ngupta has joined #openstack-keystone | 22:25 | |
*** phalmos has joined #openstack-keystone | 22:27 | |
openstackgerrit | Lance Bragstad proposed openstack/keystone-specs master: Remove the fernet key store spec from backlog https://review.openstack.org/439194 | 22:28 |
openstackgerrit | Lance Bragstad proposed openstack/keystone-specs master: Remove centralized policy delivery spec from backlog https://review.openstack.org/439195 | 22:31 |
*** chris_hultin|AWA is now known as chris_hultin | 22:36 | |
*** phalmos_ has joined #openstack-keystone | 22:42 | |
*** phalmos has quit IRC | 22:46 | |
*** adrian_otto has quit IRC | 22:50 | |
*** chris_hultin is now known as chris_hultin|AWA | 22:50 | |
*** ngupta_ has joined #openstack-keystone | 22:56 | |
*** edmondsw has joined #openstack-keystone | 22:58 | |
*** ngupta has quit IRC | 23:00 | |
*** edmondsw has quit IRC | 23:01 | |
*** ngupta_ has quit IRC | 23:01 | |
*** edmondsw has joined #openstack-keystone | 23:01 | |
*** phalmos has joined #openstack-keystone | 23:03 | |
*** phalmos_ has quit IRC | 23:06 | |
openstackgerrit | Lance Bragstad proposed openstack/keystone-specs master: Clarify bits of the alembic backlogged spec https://review.openstack.org/439205 | 23:08 |
*** lucasxu has quit IRC | 23:15 | |
openstackgerrit | Lance Bragstad proposed openstack/keystone-specs master: Remove centralized policies fetch cache spec https://review.openstack.org/439208 | 23:15 |
*** gyee has quit IRC | 23:15 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements https://review.openstack.org/439219 | 23:18 |
*** edmondsw has quit IRC | 23:18 | |
*** edmondsw has joined #openstack-keystone | 23:19 | |
*** lamt has quit IRC | 23:27 | |
*** lamt has joined #openstack-keystone | 23:28 | |
*** phalmos_ has joined #openstack-keystone | 23:30 | |
*** phalmos has quit IRC | 23:31 | |
*** lamt has quit IRC | 23:40 | |
notmorgan | well then.... | 23:44 |
notmorgan | this has slowed the tests suite down massssssively | 23:44 |
* notmorgan will need to tweak some settings... | 23:44 | |
*** edmondsw has quit IRC | 23:45 | |
*** edmondsw has joined #openstack-keystone | 23:46 | |
*** edmondsw has quit IRC | 23:50 | |
*** dave-mccowan has joined #openstack-keystone | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!