Timeline for Could this authentication/authorization flow be attacked without compromising the Authority Server?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 12, 2018 at 6:32 | history | tweeted | twitter.com/StackSecurity/status/984318420425560064 | ||
| Apr 11, 2018 at 15:52 | comment | added | Matiss | @Limit Yes, I considered the OAuth limitations. Consumer will never be able to to see Subject's password, or login using user/password against the Authority. I was considering allowing that for "trusted consumers", but that is simply not necessary - I have some ideas on how to avoid that. The only way to log in to the service is by the user to login into the Authority Server directly. Username and password never leaves Authority server and the tokens issued are bound to consumers, so a token issued to one consumer can not be used by another consumer. | |
| Apr 11, 2018 at 15:31 | comment | added | Limit | I am not sure if this is part of the threat model for OAuth or your protocol. But, is the following scenario possible? Say you have a rogue consumer. You have a single authorized service among all so I am guessing you have the same username/password for all. Since the consumer can see your username and password in plaintext, can they use them to authenticate to benign consumers and do something? | |
| Apr 11, 2018 at 14:30 | comment | added | Matiss | @NeilSmithline thank you for your insight - it is appreciated. That being said, your opinion on whether or not this is useful, should be implemented, or anything of the kind is not what is being asked for, nor what is being discussed here - the proposed flow is. If you have nothing more of value to add, or any questions that needs clarification, to which I would happily provide answers to, there surely are plenty of other questions on SXC you might actually have an answer to. | |
| Apr 11, 2018 at 14:10 | comment | added | Neil Smithline | FIrst, the top-voted answer to that question is much more conservative and recommends using context. Second, this is security, not general programming - it's different. Authentication and authorization standards are created over years by a group of experts with extensive public review and revisions. The implementations are then tested before being released and then tested for real once released. Without a similar process, you will never create something as strong as an existing, robust solution. How about you tell us what your concerns are with using existing standards and we'll try to help. | |
| Apr 11, 2018 at 14:03 | comment | added | Matiss | @NeilSmithline see Is reinventing the wheel really all that bad?. | |
| Apr 11, 2018 at 13:58 | comment | added | Matiss | @Limit yes, Kerberos is often good choice, yet, I am looking to expand on the basic flow described here to provide certain features that Kerberos is not able to support, no matter how much hax. | |
| Apr 11, 2018 at 13:24 | comment | added | Neil Smithline | See Why shouldn't we roll our own?. | |
| Apr 11, 2018 at 13:18 | comment | added | Limit | Kerberos is an authentication/authorization protocol that people often use. Is there some drawback of that which made you not use it? | |
| Apr 11, 2018 at 8:56 | comment | added | Matiss | @NeilSmithline which established protocol would you suggest? | |
| Apr 11, 2018 at 2:46 | comment | added | Neil Smithline | What drawbacks are you concerned with? I really prefer going with an established protocol over a new one. | |
| Apr 10, 2018 at 17:52 | comment | added | Matiss | @A.Darwin I am leaning towards using JWT, so signed, but with explicitly forbidden none scheme and unsafe options. Also mandatory SSL for sure. | |
| Apr 10, 2018 at 17:50 | comment | added | A. Darwin | Are the tickets cleartext or encrypted? | |
| Apr 10, 2018 at 17:23 | review | First posts | |||
| Apr 10, 2018 at 18:18 | |||||
| Apr 10, 2018 at 17:22 | history | asked | Matiss | CC BY-SA 3.0 |