3 ms·
Yes I completely agree. Actually, what is the difference in security between an app that generates a key pair on first use and exchanges the public key via a 3r
by egeozcan 10y ago
Yes I completely agree. Actually, what is the difference in security between an app that generates a key pair on first use and exchanges the public key via a 3rd party servers and a web application doing exactly that. As long as the connection is secure and you trust the 3rd party for not having you send the private key to them, the model seems reasonably secure for both scenarios.
Though public key exchange can be improved on mobile by better direct communication capabilities like barcode scanning, rfid, bluetooth etc.
Am I missing something or is this more of a "JS is not reliably fast on all devices so we rather don't" kind of thing?
- WorldMaker 10y agoI assume the issue is more to do with private key storage on the device. JS provides several local storage mechanisms, but none of them have cryptographic guarantees and all are potentially vulnerable to attacks like XSS and "attacks" like development console disclosure. There's been calls for the Web Application Platform to standardize on an HTML5 "Key Store" for cryptography, but thus far it doesn't sound like any consensus has been managed to be reached on how that key store would operate. Certainly, there are mitigations such as very short lived private keys and relying on existing sandboxing and XSS protections browsers already have to do for JS local storages, but it's easy to understand how from a paranoia standpoint there's no guaranteed safe key store just yet in a browser, especially not one backed up by OS-level security guarantees as one would be able to use on mobile devices.