7 ms·

Exactly!!! Encrypting user data should be a common practice like hashing passwords.

laumars 12y ago
Why? Encrypting e-mail addresses would break password reset features and phone numbers are generally public anyway (yes you can go X-directory, but the real issue here is why these services require a valid phone number to begin with)
- schrodinger 12y ago
  Why would encrypting email addresses break password reset? You can encrypt the database at rest such that the application has a private key that can decode it. That way both the application and the database server need to be breached to obtain anything usable.
  - lucian1900 12y ago
    Or just the application. Generally, it's much easier to convince apps to give you the data instead.
  - laumars 12y ago
    It's often a bug in the application that exposes the database, so the same bugs might also be used to expose the private key. It's also worth noting that it wouldn't just be the web servers that require your private key, it would also be any mail servers you use for sending your newsletters and such like (assuming these aren't run on your web servers - which often isn't the case). Then there's your telephone support staff, who would also may need to know your e-mail address so they could do their job effectively. And any other operators that might compile data extracts, eg for 3rd parties where users have given permission for your details to used / sold. Quickly you're in a situation where your private key is more available across your infrastructure than the e-mail would have been if it wasn't encrypted to begin with. Now lets look at the cost of such a system. There's an obvious electricity / hardware cost with the CPU time required to encrypt / decrypt this data (after all, CPU time is the general measure for the strength of encryption) and the staffing cost with the time wasted jumping through those extra hoops. The development time, code complexity, etc - it all has a cost to the company. So what's the benefits in any companies doing this? They don't gain any extra security? This is really more of a privacy policy for their users; and users which are that paranoid about their e-mail address being leaked should either use a disposable e-mail account or shouldn't be using a cloud-based proprietary messenging network to begin with. What's more the chat history might well have your e-mail address in anyway (eg "hi dave, I'm heading into a meeting shortly, but e-mail me at bob@example.com and I'll have a look tonight") Don't get me wrong, I'm all for hashing / encrypting sensitive data. But pragmatically we need to consider: 1) are e-mail addresses really that sensitive? Or instead should we be encouraging better security for our web-mail et al accounts (eg 2 factor authentication) to prevent our addresses being abused. Given that we give out e-mail addresses to anyone who needs to contact us, I think the latter option (securing our email accounts) is the smarter one 2) instead of encrypting phone numbers and postal addresses, should we instead be challenging the requirement for online services to store them to begin with? If they have my email address, why do they also need my phone number? Postal address I can forgive a little more if there's a product that needs shipping or payments that need to be made.
scrollaway 12y ago
Third party authentication should be the norm. Leaving authentication to providers that absolutely know their shit, just like we leave payments to third party services. Of course, that requires a decent protocol, and Mozilla is doing the world a disservice in not marketing Persona better seeing as it's the right solution....
- santosha 12y ago
  Major privacy issues, single point of failure etc etc. We leave payments to third party services because nobody wants to deal with the compliance nightmare that PCI-DSS is, not for security reasons. Payment is also mostly less sensitive to availability and latency issues than authentication.
  - scrollaway 12y ago
    So in a world where PCI-DSS isn't a thing, you're fine entering your credit card data directly on the forms available on random websites? Why's a password so different, seeing as most people reuse those passwords? Why do we essentially allow (and yes, I am excluding those that use password managers in this statement, I'm one of those) access to our webmail and other critical services to random websites on the internet? What makes this right? > Payment is also mostly less sensitive to availability and latency issues than authentication. That's patently untrue. Latency issues are nonexistant in both areas, and availability issues are critical in both areas.
    - makeitsuckless 12y ago
      Yes, I have no problem entering my credit card data directly on the forms available on random websites. Credit card payments online are so ludicrously insecure that it baffles me it's even legal. I only use them when dealing with the US (although some of the major retailers like Apple have finally started accepting 21st century payment methods), and I simply assume my credit card info has been leaking all over the place for ages. The whole basic premise of credit cards is "we know it's totally broken, we'll just refund you the money because it's cheaper than fixing the problem".
Erwin 12y ago
You never decrypt a password however. You only compare the hashed version of the claimed one to the stored hashed version, a one-way operation. What could you do with a one-way encrypted phone number? I'm not able to enter a phone hash to make a call.
- laumars 12y ago
  Encryption isn't the same as hashing. Encryption is two-way. The previous comment did make the encryption / hash distinction - though I can totally understand how his post might have been misread that he was recommending the same mechanisms for both sets of data.
  - Erwin 12y ago
    OK, so slack stores a username, name and email address for each user. This is visible to everyone else in the same Slack team at minimum. You also need it for e.g. password resets, perhaps billing. We can assume they aren't total idiots and there's a Internet facing application server that connects to a internal-only database server that has this data. Also, assume SQL injection is not the attack vector. How would you apply encryption to protect the username, name and email from an attacker that has gained access to the application server? I've gained some shell on the server and have 24 hours minutes to extract data. I can see all the files on the server but maybe as non-root but just the user that runs the application. How can you, as a security sensitive application developer, stop me if I've gotten so far?
    - laumars 12y ago
      I wouldn't. I don't agree with his point either (see my response to him: https://news.ycombinator.com/item?id=9277659 https://news.ycombinator.com/item?id=9277659).
atmosx 12y ago
> Exactly!!! > Encrypting user data should be a common practice like hashing passwords. I get the feeling that you've never done this before and you don't understand the technical challenge and implications of the added complexity you propose here for an essentially free to low-price all-in-one communication online service. Slack is not the NSA, encryption is not the answer to every security problem out there.

Why? Encrypting e-mail addresses would break password reset features and phone numbers are generally public anyway (yes you can go X-directory, but the real issue here is why these services require a valid phone number to begin with)

schrodinger 12y ago
Why would encrypting email addresses break password reset? You can encrypt the database at rest such that the application has a private key that can decode it. That way both the application and the database server need to be breached to obtain anything usable.
- lucian1900 12y ago
  Or just the application. Generally, it's much easier to convince apps to give you the data instead.
- laumars 12y ago
  It's often a bug in the application that exposes the database, so the same bugs might also be used to expose the private key. It's also worth noting that it wouldn't just be the web servers that require your private key, it would also be any mail servers you use for sending your newsletters and such like (assuming these aren't run on your web servers - which often isn't the case). Then there's your telephone support staff, who would also may need to know your e-mail address so they could do their job effectively. And any other operators that might compile data extracts, eg for 3rd parties where users have given permission for your details to used / sold. Quickly you're in a situation where your private key is more available across your infrastructure than the e-mail would have been if it wasn't encrypted to begin with. Now lets look at the cost of such a system. There's an obvious electricity / hardware cost with the CPU time required to encrypt / decrypt this data (after all, CPU time is the general measure for the strength of encryption) and the staffing cost with the time wasted jumping through those extra hoops. The development time, code complexity, etc - it all has a cost to the company. So what's the benefits in any companies doing this? They don't gain any extra security? This is really more of a privacy policy for their users; and users which are that paranoid about their e-mail address being leaked should either use a disposable e-mail account or shouldn't be using a cloud-based proprietary messenging network to begin with. What's more the chat history might well have your e-mail address in anyway (eg "hi dave, I'm heading into a meeting shortly, but e-mail me at bob@example.com and I'll have a look tonight") Don't get me wrong, I'm all for hashing / encrypting sensitive data. But pragmatically we need to consider: 1) are e-mail addresses really that sensitive? Or instead should we be encouraging better security for our web-mail et al accounts (eg 2 factor authentication) to prevent our addresses being abused. Given that we give out e-mail addresses to anyone who needs to contact us, I think the latter option (securing our email accounts) is the smarter one 2) instead of encrypting phone numbers and postal addresses, should we instead be challenging the requirement for online services to store them to begin with? If they have my email address, why do they also need my phone number? Postal address I can forgive a little more if there's a product that needs shipping or payments that need to be made.

scrollaway 12y ago

Third party authentication should be the norm. Leaving authentication to providers that absolutely know their shit, just like we leave payments to third party services. Of course, that requires a decent protocol, and Mozilla is doing the world a disservice in not marketing Persona better seeing as it's the right solution....

santosha 12y ago
Major privacy issues, single point of failure etc etc. We leave payments to third party services because nobody wants to deal with the compliance nightmare that PCI-DSS is, not for security reasons. Payment is also mostly less sensitive to availability and latency issues than authentication.
- scrollaway 12y ago
  So in a world where PCI-DSS isn't a thing, you're fine entering your credit card data directly on the forms available on random websites? Why's a password so different, seeing as most people reuse those passwords? Why do we essentially allow (and yes, I am excluding those that use password managers in this statement, I'm one of those) access to our webmail and other critical services to random websites on the internet? What makes this right? > Payment is also mostly less sensitive to availability and latency issues than authentication. That's patently untrue. Latency issues are nonexistant in both areas, and availability issues are critical in both areas.
  - makeitsuckless 12y ago
    Yes, I have no problem entering my credit card data directly on the forms available on random websites. Credit card payments online are so ludicrously insecure that it baffles me it's even legal. I only use them when dealing with the US (although some of the major retailers like Apple have finally started accepting 21st century payment methods), and I simply assume my credit card info has been leaking all over the place for ages. The whole basic premise of credit cards is "we know it's totally broken, we'll just refund you the money because it's cheaper than fixing the problem".

Erwin 12y ago

You never decrypt a password however. You only compare the hashed version of the claimed one to the stored hashed version, a one-way operation. What could you do with a one-way encrypted phone number? I'm not able to enter a phone hash to make a call.

laumars 12y ago
Encryption isn't the same as hashing. Encryption is two-way. The previous comment did make the encryption / hash distinction - though I can totally understand how his post might have been misread that he was recommending the same mechanisms for both sets of data.
- Erwin 12y ago
  OK, so slack stores a username, name and email address for each user. This is visible to everyone else in the same Slack team at minimum. You also need it for e.g. password resets, perhaps billing. We can assume they aren't total idiots and there's a Internet facing application server that connects to a internal-only database server that has this data. Also, assume SQL injection is not the attack vector. How would you apply encryption to protect the username, name and email from an attacker that has gained access to the application server? I've gained some shell on the server and have 24 hours minutes to extract data. I can see all the files on the server but maybe as non-root but just the user that runs the application. How can you, as a security sensitive application developer, stop me if I've gotten so far?
  - laumars 12y ago
    I wouldn't. I don't agree with his point either (see my response to him: https://news.ycombinator.com/item?id=9277659 https://news.ycombinator.com/item?id=9277659).

atmosx 12y ago

> Exactly!!! > Encrypting user data should be a common practice like hashing passwords. I get the feeling that you've never done this before and you don't understand the technical challenge and implications of the added complexity you propose here for an essentially free to low-price all-in-one communication online service. Slack is not the NSA, encryption is not the answer to every security problem out there.