<p><br>
On Aug 16, 2014 7:54 PM, "John Denker" <<a href="mailto:jsd@av8n.com">jsd@av8n.com</a>> wrote:<br>
></p>
<p>><br>
> To those who think this cannot be done, or who think it would be<br>
> unduly burdensome, here is a counterargument by way of analogy:<br>
><br>
> I run very little risk that any online merchant will compromise my<br>
> credit-card account, because my bank provides an app that generates<br>
> ephemeral credit-card numbers, one per transaction.  The virtual<br>
> card has a credit limit that suffices to cover that one transaction<br>
> and nothing more, so the merchant cannot overcharge me.  Also, the<br>
> virtual card is locked to a particular merchant, so even if the<br>
> balance is not used up, stealing the card number would be of no<br>
> use to anybody else.  I could safely publish all my past card numbers<br>
> on my web site.<br>
><br>
> There are some important ideas here, including:<br>
>   a) ease of use, and<br>
>   b) seamless compatibility with the huge installed base of vendors<br>
>    who ask for a credit-card number.<br>
><br>
> Part of the ease-of-use comes from the fact that the virtual card<br>
> app uses "automatic form filling" to stuff the card number, date,<br>
> cardholder name, etc. into the merchant's form.  This makes it<br>
> actually /easier/ to use than a non-virtual plastic card.<br>
><br>
> Furthermore it is vastly /more secure/ than a plastic card,<br>
> because in addition to identification and authentication, it<br>
> provides /authorization/ for a particular dollar amount.<br>
><br>
> Migration away from the existing addiction to passwords will not<br>
> be quite so smooth, but there is no doubt that it can be done.<br>
> The "automatic form filling" features can be put to good use<br>
> here.<br>
></p>
<p>Well, isn't what you've described actually accomplished, less fees, with Bitcoin?</p>
<p>As to passwords, what about a two step auth system which involved both password and possession of a data file.</p>