Kill Your Users Table(blog.wekeroad.com)
blog.wekeroad.com
Kill Your Users Table
http://blog.wekeroad.com/blog/kill-your-users-table/
12 comments
I like this notion, but his actual suggestion isn't to kill the users table, rather to outsource it (to OpenID or a similar service).
If you're considering the encryption of passwords and not the hashing and salting of passwords, you're already in some trouble.
You don't want to decrypt passwords.
You want to hash, and compare. And only then with a cryptographically secure hash.
And you also want to consider building in some form of evasion, and quite possibly to introduce a deliberate delay in the password processing; steps to slow the inevitable password attacks.
You don't want to decrypt passwords.
You want to hash, and compare. And only then with a cryptographically secure hash.
And you also want to consider building in some form of evasion, and quite possibly to introduce a deliberate delay in the password processing; steps to slow the inevitable password attacks.
Seconded.
I would add that you should use more than one form of cryptography: one type for sensitive contact information and another for passwords. For internal support you often need to decrypt names, address, email but you don't want that same algorithm for passwords, credit cards, etc.
I would add that you should use more than one form of cryptography: one type for sensitive contact information and another for passwords. For internal support you often need to decrypt names, address, email but you don't want that same algorithm for passwords, credit cards, etc.
I've been building on Facebook's platform lately, and some of the guidelines they have (rarely followed) started me thinking in terms of gradual information request, or a JIT users table.
Need the name? Ask for it, and store it in a cookie.
Need a persistent way to refer to a particular user? Use OpenID (or the Facebook UID, in my case). What if they don't have OpenID? Have links to a few providers, and also be a super simple provider yourself, built into your app. Don't store anything you don't have to.
As you find you need more information, ask for it, and explain why you need it. Make it easy for users to remove selective pieces of information if you don't need it anymore. Help them know when that is.
Need the name? Ask for it, and store it in a cookie.
Need a persistent way to refer to a particular user? Use OpenID (or the Facebook UID, in my case). What if they don't have OpenID? Have links to a few providers, and also be a super simple provider yourself, built into your app. Don't store anything you don't have to.
As you find you need more information, ask for it, and explain why you need it. Make it easy for users to remove selective pieces of information if you don't need it anymore. Help them know when that is.
Every time I see a stupid and provocative title, I am hoping that it's something interesting and title was chosen only to attract attention.
Yet again, it was just that - stupid: if you're afraid to deal with usernames/passwords in a secure fashion, how would you deal with credit card numbers for recurring billing? Or how would you approach a task of writing a billing system for someone like AT&T?
Yet again, it was just that - stupid: if you're afraid to deal with usernames/passwords in a secure fashion, how would you deal with credit card numbers for recurring billing? Or how would you approach a task of writing a billing system for someone like AT&T?
Hmm... the application I spend all my time on doesn't include credit cards. :)
Neither does Reddit.
Neither do most web apps I can think of. They might be billed services, but that's why we have credit card gateways and prebuilt billing systems.
Neither does Reddit.
Neither do most web apps I can think of. They might be billed services, but that's why we have credit card gateways and prebuilt billing systems.
[deleted]
Most recurring billing providers handle the credit card numbers for you. So after you pass them along to their API you never need them again.
Isn't it more secure not to reinvent every wheel yourself? I'm much rather let others deal with their core competencies than spend all my new feature cycles making yet another create/confirm/forgot authentication boiler plate.
Isn't it more secure not to reinvent every wheel yourself? I'm much rather let others deal with their core competencies than spend all my new feature cycles making yet another create/confirm/forgot authentication boiler plate.
I was thinking the same thing.
"Billing and Shipping Addresses: Billing records are kept at the payment processor, and shipping is likely kept in a waybill somewhere - both accessible by your application when needed. You don't need this in your database."
I don't need to maintain the user's maintenance of it in my database, but the data that goes onto the waybill needs to be stored somewhere during the ordering process (and most likely needs to be stored for future shipment records processing/reporting), so you actually have not gained much security.
"Billing and Shipping Addresses: Billing records are kept at the payment processor, and shipping is likely kept in a waybill somewhere - both accessible by your application when needed. You don't need this in your database."
I don't need to maintain the user's maintenance of it in my database, but the data that goes onto the waybill needs to be stored somewhere during the ordering process (and most likely needs to be stored for future shipment records processing/reporting), so you actually have not gained much security.
What a gyp! This page doesn't tell me any ways to kill my users.