5 ms·

I mean, the article is generally right but they immediately get a detail wrong: > Right now, Slack stores everything you do on its platform by default — your u

I mean, the article is generally right but they immediately get a detail wrong: > Right now, Slack stores everything you do on its platform by default — your username and password ... I would be extremely surprised if they store plaintext or even encrypted passwords. Maybe the author means usernames/passwords sent in messages, but that's not unique to slack.

jeremyjh 7y ago
I’d guess the number of times a password has been shared in a private channel/direct message is a number with quite a lot of 0s behind it.
- AceyMan 7y ago
  fwiw, when I have to share a password or api key in a DM once the party acks receipt I then delete the message. Unless a snapshot is taken in the interval I reason that there won't be a persistent copy left behind. Does anyone 'behind-the-curtain' know anything that would contradict my assumptions?
  - ecnahc515 7y ago
    Those messages are certainly not deleted in the backend. They can be read by your organization's slack admins even.
    - Wowfunhappy 7y ago
      Wow. This should be considered harmful, due to exactly the scenario described by the GP! Perhaps it's true that tokens and such should not be shared on a channel like Slack to begin with, but it's also very reasonable to assume that deleted messages actually get deleted, at least absent a data forensics expert or similar.
      - ci5er 7y ago
        Why would you assume that? I (as the 'designer' of a couple of distributed event-sourced systems), will create a message (as an event) that ricochets around to update several SQL and non-SQL systems that are normalized or denormalized views, or what not. When a 'delete' command (event) gets sent around, that gets accepted by subscribers/listeners, and they 'mark' their respective 'column' equivalents as 'deleted', but in an append-only log, the idea that a disk block gets updated is kind of nonsensical. The logic goes: 1) something happened. 2) we regret it - please hide it from (most) quesry responses. I know if I was dealing with an RDBMS, it's probably easy enough to delete it, but in an eventually consistent, heterogenous, append-only world, an actual delete-delete is kind of a hassle to even contemplate.
        Wowfunhappy 7y ago
        If it needs to exist in the raw database for technical reasons, that's one thing, but it shouldn't be visible to anyone including the administrator.
        ci5er 7y ago
        If you mean the site-/team- administrator, that's probably right. (We have similar issues for HIPAA related reasons). Our production emergency debuggers, there aren't many, get a bit more leeway than they probably should because they are trying to help us respond to failures under heavy SLA penalties. The 'these-people-ran-this-query' logs are immutable, and (hopefully) keep them in check from random lookups on their ex's during some dumpster fire exercise or another.
hsnewman 7y ago
If they don't store the password encrypted or in plaintext, how would they be able to authenticate you? It must be stored somehow, either plaintext or encrypted (preferred).
- beatgammit 7y ago
  Hashed. An encrypted password can be reversed, a hashed password cannot, it can only be verified. An encrypted password is only slightly preferable to a plaintext one because you still need to store the password somewhere, which am attacker would theoretically have access to, so it mostly serves as obfuscation.
- deleted 7y ago
  [deleted]
- RHSeeger 7y ago
  Generally, hashed. Ie, not reversible.
- deleted 7y ago
  [deleted]
- sleepychu 7y ago
  There's a difference between encrypted (implies can be decrypted) and hashed (a one way function which cannot be reversed). In general, I shouldn't be able to tell you your password, I should just be able to tell you if the password you just gave me is the one you gave me before.
- swebs 7y ago
  https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt
  - lucb1e 7y ago
    I don't know if it is generally discouraged on HN, but let me just say that I find link-only answers discouraging (similar to lmgtfy) and of little value if you don't highlight the important bit. Additionally, your link is about a particular hashing scheme. Someone with no clue what hashing is will not be helped by a link to a particular hashing scheme. The first link in the article, however, gets you to a page that explains everything, and might have been a much better text to cite and link: > Password verification commonly relies on cryptographic hashes. Storing all user passwords as cleartext can result in a massive security breach if the password file is compromised. One way to reduce this danger is to only store the hash digest of each password. To authenticate a user, the password presented by the user is hashed and compared with the stored hash. A password reset method is required when password hashing is performed; original passwords cannot be recalculated from the stored hash value. https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification https://en.wikipedia.org/wiki/Cryptographic_hash_function#Pa...

jeremyjh 7y ago

I’d guess the number of times a password has been shared in a private channel/direct message is a number with quite a lot of 0s behind it.

AceyMan 7y ago
fwiw, when I have to share a password or api key in a DM once the party acks receipt I then delete the message. Unless a snapshot is taken in the interval I reason that there won't be a persistent copy left behind. Does anyone 'behind-the-curtain' know anything that would contradict my assumptions?
- ecnahc515 7y ago
  Those messages are certainly not deleted in the backend. They can be read by your organization's slack admins even.
  - Wowfunhappy 7y ago
    Wow. This should be considered harmful, due to exactly the scenario described by the GP! Perhaps it's true that tokens and such should not be shared on a channel like Slack to begin with, but it's also very reasonable to assume that deleted messages actually get deleted, at least absent a data forensics expert or similar.
    - ci5er 7y ago
      Why would you assume that? I (as the 'designer' of a couple of distributed event-sourced systems), will create a message (as an event) that ricochets around to update several SQL and non-SQL systems that are normalized or denormalized views, or what not. When a 'delete' command (event) gets sent around, that gets accepted by subscribers/listeners, and they 'mark' their respective 'column' equivalents as 'deleted', but in an append-only log, the idea that a disk block gets updated is kind of nonsensical. The logic goes: 1) something happened. 2) we regret it - please hide it from (most) quesry responses. I know if I was dealing with an RDBMS, it's probably easy enough to delete it, but in an eventually consistent, heterogenous, append-only world, an actual delete-delete is kind of a hassle to even contemplate.
      - Wowfunhappy 7y ago
        If it needs to exist in the raw database for technical reasons, that's one thing, but it shouldn't be visible to anyone including the administrator.
        ci5er 7y ago
        If you mean the site-/team- administrator, that's probably right. (We have similar issues for HIPAA related reasons). Our production emergency debuggers, there aren't many, get a bit more leeway than they probably should because they are trying to help us respond to failures under heavy SLA penalties. The 'these-people-ran-this-query' logs are immutable, and (hopefully) keep them in check from random lookups on their ex's during some dumpster fire exercise or another.

hsnewman 7y ago

If they don't store the password encrypted or in plaintext, how would they be able to authenticate you? It must be stored somehow, either plaintext or encrypted (preferred).

beatgammit 7y ago
Hashed. An encrypted password can be reversed, a hashed password cannot, it can only be verified. An encrypted password is only slightly preferable to a plaintext one because you still need to store the password somewhere, which am attacker would theoretically have access to, so it mostly serves as obfuscation.
deleted 7y ago
[deleted]
RHSeeger 7y ago
Generally, hashed. Ie, not reversible.
deleted 7y ago
[deleted]
sleepychu 7y ago
There's a difference between encrypted (implies can be decrypted) and hashed (a one way function which cannot be reversed). In general, I shouldn't be able to tell you your password, I should just be able to tell you if the password you just gave me is the one you gave me before.
swebs 7y ago
https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt
- lucb1e 7y ago
  I don't know if it is generally discouraged on HN, but let me just say that I find link-only answers discouraging (similar to lmgtfy) and of little value if you don't highlight the important bit. Additionally, your link is about a particular hashing scheme. Someone with no clue what hashing is will not be helped by a link to a particular hashing scheme. The first link in the article, however, gets you to a page that explains everything, and might have been a much better text to cite and link: > Password verification commonly relies on cryptographic hashes. Storing all user passwords as cleartext can result in a massive security breach if the password file is compromised. One way to reduce this danger is to only store the hash digest of each password. To authenticate a user, the password presented by the user is hashed and compared with the stored hash. A password reset method is required when password hashing is performed; original passwords cannot be recalculated from the stored hash value. https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification https://en.wikipedia.org/wiki/Cryptographic_hash_function#Pa...