4 ms·

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

by rraval 10y ago

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.
    - valarauca1 10y ago
      I will say it's important to understand how the Salt we return is generated. Not in the slightest. It is the HASH of a HASH of a HASH. There is no academic rigor to support this gives you any additional security. And a lot of academic rigor that states it is a moot operation. The Salt1 is still private on the site's server, and no passwords can be cracked without it. 1) If you argue any SALT is private... Then WHY EVEN USE SALTS?!?! If something on the database is private/secure why not use clear text passwords? The whole idea of using SALT+HMAC is that NOTHING stored is private/secure. You cannot EVER assume SALT(s) are private. 2) Cracking the password is irrelevant. All that is needed is: SALT2 + Web transferred hash Then the credentials are gained. Yes learning somebody's password, or several million's peoples password is a fun experiment but gaining access to the website is also an attack vector, one your system is making easier. For a traditional HMAC/Scrypt/Bcrypt recovering the password is a critical part of this as the authentication mechanism is a single black box program. Input is SALT+Password+Hash. Output is an auth token. The system you describes breaks this dichotomy. No longer must the password be broken to gain access. :.:.: Availability is a legitimate concern An extreme one Similar to SMS multifactor SMS Multi-factor is depreciated. Faking SMS from an arbitrary phone number is extremely trivial in practice. Look into Dave Kennedy's work on social engineering. Multi-Factor auth is best done via Tokens or TOTP. We direct peer to many of our customers and route over private IP space to avoid a potential DDoS. So instead you want to just install your own box on the customers network? This opens up even more headaches about managing and authenticating your access to their private LAN. Then you get into patching agreements, possible OS limitations, security audits. This is a horrible solution for both parties.
  - mioelnir 10y ago
    > 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. If I understand that correctly, then for a 256bit hash with an internal state of 1024 bit, initialized to a fixed and public nothing-up-my-sleeve set of values, increasing the salt from 256 bit to 1024 bit - going from 1 random bit for every 4 known bits to 1 for 1 - reduces entropy. If from there we assume that the hash uses a Merkle-Darmgard block construction for which it is proven that the only loss of entropy comes from the compression function, this would - for me - mean that the chosen compression function loses more entropy on random bits than on the initialization vector, which makes it special, although it is supposedly chosen to be not special in any way. This confuses me, but I'm just a sysadmin not a cryptographer, so that is ok. Do you have any links for me to follow up on this?
zaroth 10y ago
Brief marketing intro: https://taplink.co/technology/ https://taplink.co/technology/ Technical Whitepaper: https://taplink.co/wp-content/uploads/2016/10/TapLink_Blind_Hashing_Whitepaper.pdf https://taplink.co/wp-content/uploads/2016/10/TapLink_Blind_... My talk at Passwords^15: https://www.youtube.com/watch?v=uuX_RFV1zr8 https://www.youtube.com/watch?v=uuX_RFV1zr8

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

by 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.
  - valarauca1 10y ago
    I will say it's important to understand how the Salt we return is generated. Not in the slightest. It is the HASH of a HASH of a HASH. There is no academic rigor to support this gives you any additional security. And a lot of academic rigor that states it is a moot operation. The Salt1 is still private on the site's server, and no passwords can be cracked without it. 1) If you argue any SALT is private... Then WHY EVEN USE SALTS?!?! If something on the database is private/secure why not use clear text passwords? The whole idea of using SALT+HMAC is that NOTHING stored is private/secure. You cannot EVER assume SALT(s) are private. 2) Cracking the password is irrelevant. All that is needed is: SALT2 + Web transferred hash Then the credentials are gained. Yes learning somebody's password, or several million's peoples password is a fun experiment but gaining access to the website is also an attack vector, one your system is making easier. For a traditional HMAC/Scrypt/Bcrypt recovering the password is a critical part of this as the authentication mechanism is a single black box program. Input is SALT+Password+Hash. Output is an auth token. The system you describes breaks this dichotomy. No longer must the password be broken to gain access. :.:.: Availability is a legitimate concern An extreme one Similar to SMS multifactor SMS Multi-factor is depreciated. Faking SMS from an arbitrary phone number is extremely trivial in practice. Look into Dave Kennedy's work on social engineering. Multi-Factor auth is best done via Tokens or TOTP. We direct peer to many of our customers and route over private IP space to avoid a potential DDoS. So instead you want to just install your own box on the customers network? This opens up even more headaches about managing and authenticating your access to their private LAN. Then you get into patching agreements, possible OS limitations, security audits. This is a horrible solution for both parties.
- mioelnir 10y ago
  > 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. If I understand that correctly, then for a 256bit hash with an internal state of 1024 bit, initialized to a fixed and public nothing-up-my-sleeve set of values, increasing the salt from 256 bit to 1024 bit - going from 1 random bit for every 4 known bits to 1 for 1 - reduces entropy. If from there we assume that the hash uses a Merkle-Darmgard block construction for which it is proven that the only loss of entropy comes from the compression function, this would - for me - mean that the chosen compression function loses more entropy on random bits than on the initialization vector, which makes it special, although it is supposedly chosen to be not special in any way. This confuses me, but I'm just a sysadmin not a cryptographer, so that is ok. Do you have any links for me to follow up on this?

zaroth 10y ago

Brief marketing intro: https://taplink.co/technology/ https://taplink.co/technology/ Technical Whitepaper: https://taplink.co/wp-content/uploads/2016/10/TapLink_Blind_Hashing_Whitepaper.pdf https://taplink.co/wp-content/uploads/2016/10/TapLink_Blind_... My talk at Passwords^15: https://www.youtube.com/watch?v=uuX_RFV1zr8 https://www.youtube.com/watch?v=uuX_RFV1zr8