<p dir="ltr"><br>
Den 17 jun 2015 05:12 skrev "John Denker" <<a href="mailto:jsd@av8n.com">jsd@av8n.com</a>>:<br>
><br>
> On 06/16/2015 04:19 PM, Randy Bush wrote:<br>
><br>
> > do not store critical secrets on others' systems.  period.  then, learn<br>
> > how to secure your own system(s); this is seriousy hard.<br>
><br>
> There are several ideas there.  My comments:<br>
><br>
> 1) You have to secure your own system FIRST.  To say<br>
>    the same thing the other way:  If you enter your<br>
>    password via a platform that has been pwned, then ....<br>
>   -- It doesn't matter how good your master pw is.<br>
>   -- Also it doesn't matter whether or not you use<br>
>    lastpass or anything like that, and it doesn't<br>
>    matter whether you consider lastpass to be better<br>
>    than nothing or worse than nothing.<br>
>   -- Also it doesn't matter whether you use zero-<br>
>    knowledge authentication or anything like that.</p>
<p dir="ltr">Agreed. Hardware tokens for key management is the easiest solution. Yubikey, smartcards, etc. </p>
<p dir="ltr">> 3c) The only way I can see to solve the password fatigue<br>
>  problem is to get web services to stop asking for a<br>
>  per-site password and instead use some sort of zero-<br>
>  knowledge authentication.  Schemes for doing this have<br>
>  been known for a long time.<br>
>    <a href="https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol">https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol</a><br>
><br>
> 3d) If anybody knows of a better solution, please let<br>
>  us know.</p>
<p dir="ltr">FIDO Alliance has these neat protocols, U2F for hardware tokens (uses USB HID, will support NFC) and UAF for local software.</p>
<p dir="ltr">It uses unique auth keypairs per-server, generated by the device used to authenticate, then encrypted locally to be sent to be stored on the server, with the public key known to the server.</p>
<p dir="ltr">On auth, after entering your username, the server generates a challenge for you linked to the encrypted connection (your SSL/TLS session) such that replay/relay/MITM attacks can't work, and send your device the encrypted keypair (this way your token don't need large storage, and your use can't be linked between sites from the token some). Your device decrypts the keypair and challenge, verifies that it is linked to the current SSL connection, signs the challenge, encrypts it to the server, sends it back. </p>
<p dir="ltr">Making it good enough even for use with multiple independent pseudonyms over Tor. Only technical attacks against your local software has any chance of success, and as per #1, if they can attack your local software you failed already. </p>
<p dir="ltr">This scheme has support by Microsoft, Google, Yubico, Qualcomm and more. Win10 will support it natively. </p>
<p dir="ltr">Combine with a PIN to unlock the token or similar and you've got pretty good *simple* security. </p>