The cheapest way is to periodically print out and mail sheets of indexed TAN to the user. Make it four digit index and six number passcode or something like that and it's plenty strong and still easy to use.

The cheapest way is to periodically print out and mail sheets of indexed TAN to the user. Make it four digit index and six number passcode or something like that and it's plenty strong and still easy to use.

Never really saw the need for electronic gadgets to do the above.

International mailings are slow, expensive and barely reliable. This is something your local bank might be able to do, but not Mt. Gox or Tradehill.

With the 0.01wxyz 0/? confirmation bitcoin login - only the user owning the username knows what wxyz the service provider requires (displayed in https),

and

Only the User owning the username can send the 0.01wxyz number of btc from the associated address to his account with the service provider (he owns the wallet.dat and only him can send from the associated address)

Thus ensuring trust with the Bitcoin network at no cost - to enable trusted second layer login in addition to username, password combinations. The waiting time should not be that long for the 0/? confirmation to propagate through the distributed/decentralized bitcoin network from the user to the service provider - mostly instantaneous. Double spending is not of importance in this instance. The balance of the user's account with the service provider can be adjusted only after more confirmations, enabling the user to transfer the random bitcoins again for other uses.

Disclaimer: Postings of Cloud9 are only individual views of opinion and/or musings and/or hypothesisses. On a non-authoritative, peer-to-peer public forum, you do not need permission from Cloud9 to derive your own conclusions or opinions, so please do. Calculations and assumptions to be verified.

Only the User owning the username can send the 0.01wxyz number of btc from the associated address to his account with the service provider (he owns the wallet.dat and only him can send from the associated address)

While the idea that only the owner of the wallet can send from said address sounds nice, I'm sure this will cost endless grief in real life. For one thing, users of online wallets cannot use this system, and users that have their own wallet really have to know what they're doing in order to send from a certain address. It may be secure, but certainly not user friendly.

Only the User owning the username can send the 0.01wxyz number of btc from the associated address to his account with the service provider (he owns the wallet.dat and only him can send from the associated address)

While the idea that only the owner of the wallet can send from said address sounds nice, I'm sure this will cost endless grief in real life. For one thing, users of online wallets cannot use this system, and users that have their own wallet really have to know what they're doing in order to send from a certain address. It may be secure, but certainly not user friendly.

Cheers,

Here comes the opensource implementation bitcoinjs (webcoin), a webbased java client to the rescue , allowing bitcoin webservices where you keep your eeny, weeny, tiny kilbytes wallet.dat file on your local machine and separated from the gigantic, bulky, chunky, monstrous soon to be gigabytes blockchain file which is now for this service kept centrally on a server (and this centrally kept blockchain can be verified against other sources of the blockchain for the paranoid).

Disclaimer: Postings of Cloud9 are only individual views of opinion and/or musings and/or hypothesisses. On a non-authoritative, peer-to-peer public forum, you do not need permission from Cloud9 to derive your own conclusions or opinions, so please do. Calculations and assumptions to be verified.

International mailings are slow, expensive and barely reliable. This is something your local bank might be able to do, but not Mt. Gox or Tradehill.

I would like to see more federated authentication (OpenID). Then, whether we authenticate with PGP or mailed TAN, we can use the same authentication token for many services in the bitcoin community. Services like OpenID haven't taken off due to the chicken-egg problem. Well, we're a huge clutch of chickens! let's lay some eggs.

International mailings are slow, expensive and barely reliable. This is something your local bank might be able to do, but not Mt. Gox or Tradehill.

I would like to see more federated authentication (OpenID). Then, whether we authenticate with PGP or mailed TAN, we can use the same authentication token for many services in the bitcoin community. Services like OpenID haven't taken off due to the chicken-egg problem. Well, we're a huge clutch of chickens! let's lay some eggs.

I'm making an app on google's appengine and was considering using OpenID for user authentication....researched it quite a bit, but openid on appengine dont work with https... so that kicks that idea to the curb for now.

Google's own implementation of openid works on appengine https, but you require a google account....and I'm not sure everyone who uses my service would accept that....but i might go that route anyway due to the complete ease of implementation and the fact that all the messy bits are taken care of by someone else. If true openid over appengine's https becomes available, i could then easily add that....but for now, a google account is required afik.

I bet at least 50% of my potential users would run away if they needed a google account to log into my site. What do you think?

I'm making an app on google's appengine and was considering using OpenID for user authentication....researched it quite a bit, but openid on appengine dont work with https... so that kicks that idea to the curb for now.

Google's own implementation of openid works on appengine https, but you require a google account....

Let us not call Google or Facebook authentication OpenID. They both are OpenID providers, but not consumers. No one wants twenty disparate OpenID's. Users want one (or many that they have 100% control over). In other words, Google and Facebook will let you login to other sites with your Google or Facebook id, but neither will let you login to their own sites with other identities.

I think the odds of guessing the next random number from a smart phone is going to be rough ...

why can't I have a app that app on my smart phone app that sends a random number to mt gox or tradehill (only good for 3 mins) that I have to enter in to the site to login

Not sure how that would solve a database hack (like at gox) but would require someone to break the password and have the verified cell phone (over sms, an android app could watch for it in setting up the phone the first time)

It would allow me to not have to buy some key, and what happens when I lose/break the key ?

(1) To set up my 2-factor login, I send you a string of 260 symbols, to be interpreted as a passcard with 10 rows (0-9) and 26 columns (A-Z).

The problem with this method is that if you are sending this information over the internet then it has failed since most trojans record all HTTP traffic

Theory versus practice. In theory, you're bugged all the time, forever. In practice, there is a notion of before and after. Yes, if you caught my code when I sent it, then I'm no safer (and no worse off). But if you came along *later* and started snooping around my computer, then I am safer.

More to the point, if you are in Bulgaria taking shots at my password (or if you got your hands on the password database and eventually cracked my hash), then you still can't log into my account. (Unless you also crack my 260-symbol random passcard -- good luck with that).

I'm not sure why practical measures like this are given little or no weight by the security community. They always seem to be seeking the perfect system, rather than looking for simple practical improvements. However, I freely admit that I don't know all the issues, so maybe they have very good reasons for taking that approach (like, having been burnt so many times in the past).