Author: Melvin Carvalho 2013-11-06 03:01:48
Published on: 2013-11-06T03:01:48+00:00
In response to a proposal for replacing passwords with digital signatures, Slush suggests that the message-to-be-signed should be carefully composed to be both structured and human-readable. This includes desired username/identity handler, server identifier (URL), timestamp to prevent replay attack, and server challenge. He also suggests that the same structured data should be a part of an HTML page in some header tag, ideally signed by server certificate to confirm that the request is valid. Slush raises concerns about where the private keys are stored, but suggests that client-side certificates can be used to solve this problem. Slush explains two methods for using client-side certificates: Method 1 involves putting your Bitcoin address in the subjectAlternativeName field of your client-side certificate and looking up some items previously uploaded via a ".well-known" key server. Method 2 involves putting an HTTP address in your client-side certificate, which contains your Bitcoin address and a signed copy of your cert public key or the cert itself. Both methods work, and Slush has been using them for over five years. In celebration of the 5-year anniversary of the Bitcoin whitepaper, a new Message Signing based authentication method is introduced. The authentication works by having the server provide a token for the client to sign, then the client passes the signed message and Bitcoin address back to the server, which validates the message and honors the alias (optional) and Bitcoin address as identification. A proof of concept forum that utilizes this authentication method is provided, which only stores the signed message and Bitcoin address that users provide the first time they use the site. All source code will be available on Github in the next few days.
Updated on: 2023-06-07T18:56:11.776272+00:00