MikesMechanix
Member
Offline
Activity: 70
Merit: 10
|
|
July 05, 2011, 08:04:59 AM |
|
One-time-passwords don't need to be that strong. 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.
|
|
|
|
lebuen
|
|
July 05, 2011, 08:11:41 AM |
|
One-time-passwords don't need to be that strong. 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.
|
|
|
|
cloud9
Member
Offline
Activity: 126
Merit: 10
|
|
July 05, 2011, 08:21:36 AM |
|
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.
|
|
|
|
kseistrup
|
|
July 05, 2011, 08:29:09 AM |
|
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,
|
Klaus Alexander Seistrup
|
|
|
cloud9
Member
Offline
Activity: 126
Merit: 10
|
|
July 05, 2011, 08:45:32 AM |
|
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).
|
|
|
|
|
netrin
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
July 05, 2011, 06:21:41 PM |
|
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.
|
|
|
|
indicasteve
|
|
July 05, 2011, 07:31:03 PM |
|
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?
|
|
|
|
netrin
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
July 05, 2011, 10:23:57 PM |
|
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 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?
As much as I like Google, using their authentication method for money gives me the willies. Depends on what your plans are. Maybe it's just a proof of concept and you can take it from there.
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
July 05, 2011, 11:54:29 PM |
|
i like my Yubikey
|
|
|
|
|
vectorvictor (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
July 06, 2011, 03:03:48 PM |
|
On topic, csshih posted this to the Trading section: http://forum.bitcoin.org/index.php?topic=26385.0Mt.Gox is introducing Yubikeys (a USB device for 2FA), currently in beta to ~50 users. They will be making them available for purchase for $30 (BTC accepted, naturally). The bashers can't bash that!
|
|
|
|
anthony.selby
Newbie
Offline
Activity: 42
Merit: 0
|
|
July 07, 2011, 10:13:27 PM |
|
I Love the smart phone app id ....
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 ?
|
|
|
|
ikonic
Newbie
Offline
Activity: 15
Merit: 0
|
|
July 08, 2011, 12:01:36 AM |
|
(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
|
|
|
|
error
|
|
July 08, 2011, 03:06:28 AM |
|
(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 Over https?
|
3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
|
|
|
legion050
Newbie
Offline
Activity: 51
Merit: 0
|
|
July 08, 2011, 07:45:27 AM |
|
I have used that before, works well.
|
|
|
|
vectorvictor (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
|
July 11, 2011, 05:46:04 AM |
|
(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).
|
|
|
|
|