7 ms·

Do you have a description of how you made your own security and what it provides?

bullen 7y ago
Last time I described it here on HN there was confusion. It's just "single serving server salt" (try saying that fast 3 times) sent to "client for secret hashing" and then "sent back to server again", so it's insecure on registration (just like all security with MITM without common pre-shared secret) but after that it's pretty rock solid, even quantum safe. Requires two request/responses per auth. though. This tech is nothing new and has been used by many big actors since forever. It's simpler that public/private encryption because it only requires hashing math to work. It should be my choice to use whatever encryption I want without having google scare away my customers with "Not Secure".
- necovek 7y ago
  But "common pre-shared secret" (well, public key allowing verification that there is a trusted secret being used) is at the root of https security today (a preset list of root certificates distributed with OSes/browsers). If someone presents as your web site to a first time visitor (or a previous visitor but on a new device), there is no way for them to really trust your web site. Basically, it's the equivalent of you using self-signed certs, and likely even worse because there are more attack vectors even outside the initial connection.
  - bullen 7y ago
    Can you explain how root certificates makes anything secure? Why can't you just hack the root cert store on the local computer f.ex.? There must be a million attack vectors to that system too, with a lot of attackers working on them since the payout is good when everyone uses the same system? Even if it makes sense, since all governmental offices and some corporations have their own; doesn't that make you skeptic of that kind of centralized security? I'd rather take my risks with something I can understand, modify and improve; than using what everyone else uses. And again: It should be MY choice! Not googles, now I have to compile my own browser, which takes like 24 hours on a modern home PC!!!
    - necovek 7y ago
      You are conflating multiple things. If you are on an untrusted device (eg. someone else could have hacked the root cert store in the OS/browser), all bets are off: they could have also just hacked the browser to drop any and all warnings and to always display a green padlock icon. If you are talking about someone else hacking your machine, well, then it's pretty much the same: they can get most stuff by adding keyloggers, screen recorders and just scraping your disk for useful data. If you are on a trusted device, you can "hack" the root cert store all you want to add root certificates you trust. As long as you trust them, no trust has been lost. Root certificates are not really "centralized": they are issued by different CAs, and different browsers trust different root CAs too, and it was even more prominent in the past where you had some certs "work" in only some browsers. Still, there are multiple recognised attack vectors there as well (each individual CA, their certificate issuing servers which have access to the root or intermediate signing cert, browsers and OSes and their trusted-CA components...), and the big difference is that the attack vectors are known and heavily monitored. PGP/GPG keyrings were basically the same approach without the root certificates, and the (in)famous signing parties did not bring a trust level that is ultimately needed on the internet today. I would love to see a development in that direction (one could say it was an early consensus-building approach on who to trust), but we are not there yet. It certainly is your choice to how you want to protect yourself and your web site visitors, and it's your web site visitors' choice whether they want to trust you with their data (for instance, I personally would recommend you to set up a self-signed cert and add that root cert to your keyring for services that you plan to only access yourself through untrusted networks). Except that most people won't understand where the risks are in either approach, and that's half the battle.

Last time I described it here on HN there was confusion. It's just "single serving server salt" (try saying that fast 3 times) sent to "client for secret hashing" and then "sent back to server again", so it's insecure on registration (just like all security with MITM without common pre-shared secret) but after that it's pretty rock solid, even quantum safe. Requires two request/responses per auth. though. This tech is nothing new and has been used by many big actors since forever. It's simpler that public/private encryption because it only requires hashing math to work. It should be my choice to use whatever encryption I want without having google scare away my customers with "Not Secure".

necovek 7y ago
But "common pre-shared secret" (well, public key allowing verification that there is a trusted secret being used) is at the root of https security today (a preset list of root certificates distributed with OSes/browsers). If someone presents as your web site to a first time visitor (or a previous visitor but on a new device), there is no way for them to really trust your web site. Basically, it's the equivalent of you using self-signed certs, and likely even worse because there are more attack vectors even outside the initial connection.
- bullen 7y ago
  Can you explain how root certificates makes anything secure? Why can't you just hack the root cert store on the local computer f.ex.? There must be a million attack vectors to that system too, with a lot of attackers working on them since the payout is good when everyone uses the same system? Even if it makes sense, since all governmental offices and some corporations have their own; doesn't that make you skeptic of that kind of centralized security? I'd rather take my risks with something I can understand, modify and improve; than using what everyone else uses. And again: It should be MY choice! Not googles, now I have to compile my own browser, which takes like 24 hours on a modern home PC!!!
  - necovek 7y ago
    You are conflating multiple things. If you are on an untrusted device (eg. someone else could have hacked the root cert store in the OS/browser), all bets are off: they could have also just hacked the browser to drop any and all warnings and to always display a green padlock icon. If you are talking about someone else hacking your machine, well, then it's pretty much the same: they can get most stuff by adding keyloggers, screen recorders and just scraping your disk for useful data. If you are on a trusted device, you can "hack" the root cert store all you want to add root certificates you trust. As long as you trust them, no trust has been lost. Root certificates are not really "centralized": they are issued by different CAs, and different browsers trust different root CAs too, and it was even more prominent in the past where you had some certs "work" in only some browsers. Still, there are multiple recognised attack vectors there as well (each individual CA, their certificate issuing servers which have access to the root or intermediate signing cert, browsers and OSes and their trusted-CA components...), and the big difference is that the attack vectors are known and heavily monitored. PGP/GPG keyrings were basically the same approach without the root certificates, and the (in)famous signing parties did not bring a trust level that is ultimately needed on the internet today. I would love to see a development in that direction (one could say it was an early consensus-building approach on who to trust), but we are not there yet. It certainly is your choice to how you want to protect yourself and your web site visitors, and it's your web site visitors' choice whether they want to trust you with their data (for instance, I personally would recommend you to set up a self-signed cert and add that root cert to your keyring for services that you plan to only access yourself through untrusted networks). Except that most people won't understand where the risks are in either approach, and that's half the battle.