5 ms·

The point of scrypt is to utilize the commodity hardware to the max. Commodity hardware gives you a lot of memory IO for the buck. You can't spend the same doll

by zaroth 10y ago

The point of scrypt is to utilize the commodity hardware to the max. Commodity hardware gives you a lot of memory IO for the buck. You can't spend the same dollars and get 100x more IO on an ASIC. But you can spend the same dollars and get 100x (actually even more) faster at typical hashes like SHA256. The point is to cut down on an attacker's possible advantage by using specialized hardware. Scrypt uses memory IO so that you can "get your money's worth" by running it for 100ms on an Intel CPU. This is old-school thinking and a defensive play at trying to prevent offline attacks. The idea is impose a run-time cost on each attempt to verify a password. Defender spends it every time they try to log someone in. Attacker spends it for every guess at trying to crack a password. The new approach (well I'm quite biased since I founded a company that does this) is to add a one-time cost which is unbounded and does not impose run-time latency. We do this with a large amount of random data. Many TBs or perhaps as much as a PB. The salted hashes are entangled with the data pool with a simple API, in such a way that an attacker would need to steal the entire data pool to run an offline attack. Stealing only part of the data pool does not let you crack any passwords, even if they are trivially simple. The bigger the data pool, the easier it is to defend, and the faster the system runs and more hashes/second it supports. So, is essence it's high performance scalable security that actually stops offline attacks even after the site is breached. You use this new approach as an additive layer on top of the existing scrypt hashing that you are already doing.

eigenvalue 10y ago
It occurs to me that another benefit of this approach is that it gives you ample time and warning that an attack is occurring, because unless the attacker has physical access to the machines and can just plug in a drive, you will know that a ton of data is crossing the wire.
- zaroth 10y ago
  Precisely! We monitor the network traffic very closely. The only data over the wire is API requests/responses which are counted. Every 5 minutes we compare that against the actual number of requests performed according to the application counters. If the traffic doesn't line up, it pages the whole ops team. Every day we are looking at total network egress. It would take an attacker over 200 days to move the data pool at full line rate. It gives us time to detect and remediate the inevitable breaches without ever exposing any passwords to an attack. The best part is we don't see the login, we don't see the password, we just see the hash. And without the salt it's just a random number. We don't even know if the login is valid or invalid, and there's nothing we could do to make an invalid login appear valid. So our customers effectively retain full control over their authentication process. The hash determines where we read from the data pool. 64 bytes read from each of 64 uniformly distributed locations. The 4K result is hashed and the digest is sent back in the response. On the customer side, they use the response to run one HMAC and save the result (we call it Hash2). The original hash (Hash1) can be discarded, or if you want a way to leave the service sometime in the future, encrypted using a public key with a semantically secure (non-deterministic) algorithm. Large enterprises where we are doing pilots also tell us they like this because it defends against insider threats as well.
  - raverbashing 10y ago
    Ok but how do you associate Hash2 with a user account when the user logs in?
    - zaroth 10y ago
      Does this help? login(username, password) User = GetUser(username) Hash1 = Hash(User.Salt + password) Salt2 = BlindHash(Hash1) Hash2 = Hash(Salt2 | Hash1) return Hash2 == User.Hash
      - canes123456 10y ago
        Is it wrong to think of you as really secure, off site salt provider? At the end of the day you are just providing a really good source secure random bytes that are stored for the user. What is the security benefit of sending you the actual hash of the password? Why not just the hash of a unique user token?
        zaroth 10y ago
        That's a good way to think of it. It's important to use the password as part of the entropy so that an attacker has to make a Blind Hashing request for each attempt to crack a password versus being able to make a single request to effectively unblind it.
        canes123456 10y ago
        Actually, I think a better way to describe this is user specific peppers instead of calling it a salt.
        rthille 10y ago
        The thing sent to their service shouldn't be known by anyone but the user, then it can't be stolen from the website.
    - bndw 10y ago
rraval 10y ago
I'm intrigued. Do you have a link or something that I can read more about the "new approach" as you say?
- danbruc 10y ago
  https://taplink.co/technology/ https://taplink.co/technology/
  - valarauca1 10y ago
    This is snake oil. You are just doing 4 additional HMAC salts and pretending the data is more secure. This doesn't give you any additional security. H1 = HMAC(Salt1, Password) H2 = HMAC(Salt2, H1) ---send to Company--- H3 = HMAC(Salt2, H2) H4 = HMAC(Salt3, H3) ---send back to customer--- Compare H4 with known value Ref to technical white paper: https://taplink.co/wp-content/uploads/2016/10/TapLink_Blind_Hashing_Whitepaper.pdf https://taplink.co/wp-content/uploads/2016/10/TapLink_Blind_... (I'm treating the AppID as a Hash, as I'm ignore the look up stage for the massive salt). Effectively your process can be described as: Hash = HMAC( Salt3, HMAC( Salt2, HMAC( Salt2, HMAC( Salt1, Password)))) But with network transmission?!?! Multiple salts != more security https://stackoverflow.com/questions/12753062/multiple-salts-to-protect-passwords https://stackoverflow.com/questions/12753062/multiple-salts-... https://programmers.stackexchange.com/questions/115406/is-it-more-secure-to-hash-a-password-multiple-times https://programmers.stackexchange.com/questions/115406/is-it... Also the step of shipping the final hash back to the customer is SO dangerous. TLS/SSH is secure but one miss-configuration/bug/0-day and you leak dozens of credentials. This is a really stupid model. Furthermore salts larger then the final output side offer no additional security. If you have 256bits of output, you only need 256nits of input. Larger inputs technically risk reducing the entropy of the final output. This whole security model assumes taplink.co will never get MITM. This can't be guaranteed. This also means your whole system goes down when taplink.co is out.
    - zaroth 10y ago
      That's a lot to respond to at once. :-) I will say it's important to understand how the Salt we return is generated. We use a massive pool of data as effectively the internal state of a hashing function. This means you need all the data in order to perform the same calculation. The value sent to us is just the hash of a salted hash. By itself it is useless. The value we return is Salt2 -- also useless on its own. This is very purposeful. If the TLS channel is owned, nothing of value is lost. The Salt1 is still private on the site's server, and no passwords can be cracked without it. Availability is a legitimate concern. Similar to SMS multifactor, this is an added 3rd party dependency. We direct peer to many of our customers and route over private IP space to avoid a potential DDoS.
ComodoHacker 10y ago
>The bigger the data pool, the easier it is to defend, and the faster the system runs and more hashes/second it supports. Which means these data pools will end up stored in the cloud. And in the end of the day only big players can afford sufficiently large pools. So your model encourages centralization and outsourcing of security, doesn't it?
- zaroth 10y ago
  I completely agree that very few companies can afford to run something like this on their own. So with our cloud service, you keep control of your hashing, your users, your authentication framework. You do everything you can to protect your own network and prevent a breach. But then add a, yes centralized, additional layer of security on top that which protects you even after a breach. So I absolutely agree centralization is generally evil. But what we are is a common defense fund. Everyone shares the cost of the data pool, so you pay a fraction of the overall cost, while enjoying the full security benefit. You do this without turning over control or exposing any private data. Compared this to, say, CloudFlare: we are not as worrisome because we don't see the username or the password, and we cant make an invalid login look valid. Companies are turning away from passwords and looking at SSO (talk about centralization) because storing passwords is too much of a liability. Our goal is to eliminate the liability. Eliminate password breaches, so that a simple, memorable password is secure. So it's safe for any company to store passwords and be responsible for authenticating their own users. It's a very lofty goal, and I agree it's not fully without any trade-offs, but we've been meticulously careful to design a protocol which minimizes those trade offs to the greatest degree possible. So my hope, my goal is that this tech ultimately helps maintain and support decentralized password authentication, while providing an extremely cost-efficient way to secure those hashes.
Canada 10y ago
> We do this with a large amount of random data. Many TBs or perhaps as much as a PB. What's the tradeoff in using a much smaller pool and severely rate limiting its network interface?
- zaroth 10y ago
  The protocol involves about 64 bytes in and 64 bytes response. Technically you could shrink it a bit if you needed, but let's start there. If you want 1,000 logins per second you limit yourself to 64,000 bytes / sec egress. This is hand wavy - there is some overhead but I'm not counting front-end traffic, TLS handshakes, etc. just the request/response against the internal data pool server. If you want it to take 100 days at full rate to steal the pool, then that works out to 64,000 * 60 * 60 * 24 * 100 = 552GB. You can try to set the limit even lower, to allow an even smaller pool but that's the basic math. Just 10 logins/sec --> 5.5GB. But if you depend too much on software limits and not PHY layer limits on the network speed you certainly run the risk of having your software limits blown away and the data pool slipping away much faster than you expected. You want a physical limitation to ensure the data will not get away from you over the network. When you get to the point where a successful attack would require physically removing a hundred disks which are self-encrypted SSDs then you sleep more soundly at night!
  - kbaker 10y ago
    What happens if someone is sniffing the line? It wouldn't even need to be your fault, it could be some logger on your customer's server... i.e. do you have any protection against someone including this in the client code: DEBUG("testing external service... " + Hash1) Salt2 = call_external_salt_service_api(Hash1) DEBUG("service returned: " + Salt2) If someone was logging this traffic, wouldn't this allow your service to be treated as a black box and nullify any additional security? They wouldn't need to steal the full pool in this case, as you are sending back the exact hash/salt values needed for every user that logs in.

by zaroth 10y ago

eigenvalue 10y ago

It occurs to me that another benefit of this approach is that it gives you ample time and warning that an attack is occurring, because unless the attacker has physical access to the machines and can just plug in a drive, you will know that a ton of data is crossing the wire.

zaroth 10y ago
Precisely! We monitor the network traffic very closely. The only data over the wire is API requests/responses which are counted. Every 5 minutes we compare that against the actual number of requests performed according to the application counters. If the traffic doesn't line up, it pages the whole ops team. Every day we are looking at total network egress. It would take an attacker over 200 days to move the data pool at full line rate. It gives us time to detect and remediate the inevitable breaches without ever exposing any passwords to an attack. The best part is we don't see the login, we don't see the password, we just see the hash. And without the salt it's just a random number. We don't even know if the login is valid or invalid, and there's nothing we could do to make an invalid login appear valid. So our customers effectively retain full control over their authentication process. The hash determines where we read from the data pool. 64 bytes read from each of 64 uniformly distributed locations. The 4K result is hashed and the digest is sent back in the response. On the customer side, they use the response to run one HMAC and save the result (we call it Hash2). The original hash (Hash1) can be discarded, or if you want a way to leave the service sometime in the future, encrypted using a public key with a semantically secure (non-deterministic) algorithm. Large enterprises where we are doing pilots also tell us they like this because it defends against insider threats as well.
- raverbashing 10y ago
  Ok but how do you associate Hash2 with a user account when the user logs in?
  - zaroth 10y ago
    Does this help? login(username, password) User = GetUser(username) Hash1 = Hash(User.Salt + password) Salt2 = BlindHash(Hash1) Hash2 = Hash(Salt2 | Hash1) return Hash2 == User.Hash
    - canes123456 10y ago
      Is it wrong to think of you as really secure, off site salt provider? At the end of the day you are just providing a really good source secure random bytes that are stored for the user. What is the security benefit of sending you the actual hash of the password? Why not just the hash of a unique user token?
      - zaroth 10y ago
        That's a good way to think of it. It's important to use the password as part of the entropy so that an attacker has to make a Blind Hashing request for each attempt to crack a password versus being able to make a single request to effectively unblind it.
        canes123456 10y ago
        Actually, I think a better way to describe this is user specific peppers instead of calling it a salt.
      - rthille 10y ago
        The thing sent to their service shouldn't be known by anyone but the user, then it can't be stolen from the website.
  - bndw 10y ago

rraval 10y ago

I'm intrigued. Do you have a link or something that I can read more about the "new approach" as you say?

danbruc 10y ago
https://taplink.co/technology/ https://taplink.co/technology/
- valarauca1 10y ago
  This is snake oil. You are just doing 4 additional HMAC salts and pretending the data is more secure. This doesn't give you any additional security. H1 = HMAC(Salt1, Password) H2 = HMAC(Salt2, H1) ---send to Company--- H3 = HMAC(Salt2, H2) H4 = HMAC(Salt3, H3) ---send back to customer--- Compare H4 with known value Ref to technical white paper: https://taplink.co/wp-content/uploads/2016/10/TapLink_Blind_Hashing_Whitepaper.pdf https://taplink.co/wp-content/uploads/2016/10/TapLink_Blind_... (I'm treating the AppID as a Hash, as I'm ignore the look up stage for the massive salt). Effectively your process can be described as: Hash = HMAC( Salt3, HMAC( Salt2, HMAC( Salt2, HMAC( Salt1, Password)))) But with network transmission?!?! Multiple salts != more security https://stackoverflow.com/questions/12753062/multiple-salts-to-protect-passwords https://stackoverflow.com/questions/12753062/multiple-salts-... https://programmers.stackexchange.com/questions/115406/is-it-more-secure-to-hash-a-password-multiple-times https://programmers.stackexchange.com/questions/115406/is-it... Also the step of shipping the final hash back to the customer is SO dangerous. TLS/SSH is secure but one miss-configuration/bug/0-day and you leak dozens of credentials. This is a really stupid model. Furthermore salts larger then the final output side offer no additional security. If you have 256bits of output, you only need 256nits of input. Larger inputs technically risk reducing the entropy of the final output. This whole security model assumes taplink.co will never get MITM. This can't be guaranteed. This also means your whole system goes down when taplink.co is out.
  - zaroth 10y ago
    That's a lot to respond to at once. :-) I will say it's important to understand how the Salt we return is generated. We use a massive pool of data as effectively the internal state of a hashing function. This means you need all the data in order to perform the same calculation. The value sent to us is just the hash of a salted hash. By itself it is useless. The value we return is Salt2 -- also useless on its own. This is very purposeful. If the TLS channel is owned, nothing of value is lost. The Salt1 is still private on the site's server, and no passwords can be cracked without it. Availability is a legitimate concern. Similar to SMS multifactor, this is an added 3rd party dependency. We direct peer to many of our customers and route over private IP space to avoid a potential DDoS.

ComodoHacker 10y ago

>The bigger the data pool, the easier it is to defend, and the faster the system runs and more hashes/second it supports. Which means these data pools will end up stored in the cloud. And in the end of the day only big players can afford sufficiently large pools. So your model encourages centralization and outsourcing of security, doesn't it?

zaroth 10y ago
I completely agree that very few companies can afford to run something like this on their own. So with our cloud service, you keep control of your hashing, your users, your authentication framework. You do everything you can to protect your own network and prevent a breach. But then add a, yes centralized, additional layer of security on top that which protects you even after a breach. So I absolutely agree centralization is generally evil. But what we are is a common defense fund. Everyone shares the cost of the data pool, so you pay a fraction of the overall cost, while enjoying the full security benefit. You do this without turning over control or exposing any private data. Compared this to, say, CloudFlare: we are not as worrisome because we don't see the username or the password, and we cant make an invalid login look valid. Companies are turning away from passwords and looking at SSO (talk about centralization) because storing passwords is too much of a liability. Our goal is to eliminate the liability. Eliminate password breaches, so that a simple, memorable password is secure. So it's safe for any company to store passwords and be responsible for authenticating their own users. It's a very lofty goal, and I agree it's not fully without any trade-offs, but we've been meticulously careful to design a protocol which minimizes those trade offs to the greatest degree possible. So my hope, my goal is that this tech ultimately helps maintain and support decentralized password authentication, while providing an extremely cost-efficient way to secure those hashes.

Canada 10y ago

> We do this with a large amount of random data. Many TBs or perhaps as much as a PB. What's the tradeoff in using a much smaller pool and severely rate limiting its network interface?

zaroth 10y ago
The protocol involves about 64 bytes in and 64 bytes response. Technically you could shrink it a bit if you needed, but let's start there. If you want 1,000 logins per second you limit yourself to 64,000 bytes / sec egress. This is hand wavy - there is some overhead but I'm not counting front-end traffic, TLS handshakes, etc. just the request/response against the internal data pool server. If you want it to take 100 days at full rate to steal the pool, then that works out to 64,000 * 60 * 60 * 24 * 100 = 552GB. You can try to set the limit even lower, to allow an even smaller pool but that's the basic math. Just 10 logins/sec --> 5.5GB. But if you depend too much on software limits and not PHY layer limits on the network speed you certainly run the risk of having your software limits blown away and the data pool slipping away much faster than you expected. You want a physical limitation to ensure the data will not get away from you over the network. When you get to the point where a successful attack would require physically removing a hundred disks which are self-encrypted SSDs then you sleep more soundly at night!
- kbaker 10y ago
  What happens if someone is sniffing the line? It wouldn't even need to be your fault, it could be some logger on your customer's server... i.e. do you have any protection against someone including this in the client code: DEBUG("testing external service... " + Hash1) Salt2 = call_external_salt_service_api(Hash1) DEBUG("service returned: " + Salt2) If someone was logging this traffic, wouldn't this allow your service to be treated as a black box and nullify any additional security? They wouldn't need to steal the full pool in this case, as you are sending back the exact hash/salt values needed for every user that logs in.