Timeline for Is it good to store passwords in a separate table/database and manage them in a separate process?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 26, 2016 at 15:35 | history | tweeted | twitter.com/StackSecurity/status/713751132766674944 | ||
| Mar 26, 2016 at 5:47 | answer | added | Neil Smithline | timeline score: 4 | |
| Mar 26, 2016 at 1:05 | answer | added | Tobi Nary | timeline score: 3 | |
| Mar 25, 2016 at 23:28 | comment | added | Alex Hall | I was responding to you saying I need to be careful about the linking but I see that's edited now. So what else should I be careful about? That's really the point of the question. | |
| Mar 25, 2016 at 23:27 | comment | added | Robert Mennell | well yeah that's fairly standard if they aren't in the same table. | |
| Mar 25, 2016 at 23:12 | comment | added | Alex Hall | @RobertMennell Each user will have an ID that has the same value in both the main database and the password database. When the user logs in that ID is looked up via their username/email and sent in a request to the service, which uses it to check that the password is correct. | |
| Mar 25, 2016 at 22:49 | comment | added | Robert Mennell | There's to much going on in this question. We don't need to know the algorithm, we don't need to know about the web app, and we don't need to know about if it lives on the main app server. What your question really is boils down to this: Is it a good idea to use a separate micro service to encrypt, verify, modify, and delete passwords that have a CPU intensive crypt cipher and then stores those in a separate database away from the users? The answer to that is yes, it's a good idea. Not the best, but not the worse. There are a couple of things you need to be careful of though. | |
| Mar 25, 2016 at 22:31 | history | asked | Alex Hall | CC BY-SA 3.0 |