Search content
Sort by
Showing 20 of 34 results by smartcardguy
Re: Camp BX Platform in Beta: Margin Trading, Short Selling, and Advanced Orders
Have not read the thread but 1st observations are:
1. Collecting account info in registration over http == bad
2. Registration says, now go logon; come-on why didnt you set the session cookie?
3. Collecting user id and password over http for logon means it can be taken.
4. Session cookies over http mean they can be taken even if you send creds over https.
5. Tried to logon after registration and was told account would lockout in 5 tries, sure I entered right password why cant I log in.
6. Tried to logon again still said bad password and lockout in 5 times, shouldnt it be 4?
1. Collecting account info in registration over http == bad
2. Registration says, now go logon; come-on why didnt you set the session cookie?
3. Collecting user id and password over http for logon means it can be taken.
4. Session cookies over http mean they can be taken even if you send creds over https.
5. Tried to logon after registration and was told account would lockout in 5 tries, sure I entered right password why cant I log in.
6. Tried to logon again still said bad password and lockout in 5 times, shouldnt it be 4?
More:
1. Workflow for password reset is broken, after entering my reset password was redirected to the reset password form, entered user id again got new password again, had to close that tab and navigate back since this form looks like it was intended to be in a layer.
2. My IP was banned, I tried under 10 times to log in; glad you ban on suspicious activity but I wasnt doing anything other than trying to log on, check your thresholds.
3. No account providence stuff was done, if there is money in the accounts you want to make sure they can get back in if they mess up so you need to do this.
4. Learn from the mt gox fiasco, collect enough information you can validate providence if you have to "recover" accounts.
If you would like to discuss common authn mistakes in implementations like these PM me and we can discuss in detail.
Re: Camp BX Platform in Beta: Margin Trading, Short Selling, and Advanced Orders
Have not read the thread but 1st observations are:
1. Collecting account info in registration over http == bad
2. Registration says, now go logon; come-on why didnt you set the session cookie?
3. Collecting user id and password over http for logon means it can be taken.
4. Session cookies over http mean they can be taken even if you send creds over https.
5. Tried to logon after registration and was told account would lockout in 5 tries, sure I entered right password why cant I log in.
6. Tried to logon again still said bad password and lockout in 5 times, shouldnt it be 4?
1. Collecting account info in registration over http == bad
2. Registration says, now go logon; come-on why didnt you set the session cookie?
3. Collecting user id and password over http for logon means it can be taken.
4. Session cookies over http mean they can be taken even if you send creds over https.
5. Tried to logon after registration and was told account would lockout in 5 tries, sure I entered right password why cant I log in.
6. Tried to logon again still said bad password and lockout in 5 times, shouldnt it be 4?
Re: New, simple online wallet: www.instawallet.org - no signup required
@JAV, You may also have to worry about Toolbar programs (like Alexa toolbar, Ask toolbar, Bing tool bar, Yahoo Tool Bar, Google Toolbar, lots of Firefox plugins). I believe that some of these send URLs back to the "mother ship" to help with page rankings and site analytics.
But Instawallet is a very nice looking site!
See http://www.google.com/privacy/faq.html#toc-terms-urls
URLs and embedded information
Some of our services, including Google Toolbar and Google Web Accelerator, send the uniform resource locators (URLs) of web pages that you request to Google. When you use these services, Google will receive and store the URL sent by the web sites you visit, including any personal information inserted into those URLs by the web site operator. Some Google services (such as Google Toolbar) enable you to opt-in or opt-out of sending URLs to Google, while for others (such as Google Web Accelerator) the sending of URLs to Google is intrinsic to the service. When you sign up for any such service, you will be informed clearly that the service sends URLs to Google, and whether and how you can opt-in or opt-out.
For example, when you submit information to a web page (such as a user login ID or registration information), the operator of that web site may embed that information including personal information into its URL (typically, after a question mark (?) in the URL). When the URL is transmitted to Google, our servers automatically store the URL, including any personal information that has been embedded after the question mark. Google does not exercise any control over these web sites or whether they embed personal information into URLs.
But Instawallet is a very nice looking site!
See http://www.google.com/privacy/faq.html#toc-terms-urls
URLs and embedded information
Some of our services, including Google Toolbar and Google Web Accelerator, send the uniform resource locators (URLs) of web pages that you request to Google. When you use these services, Google will receive and store the URL sent by the web sites you visit, including any personal information inserted into those URLs by the web site operator. Some Google services (such as Google Toolbar) enable you to opt-in or opt-out of sending URLs to Google, while for others (such as Google Web Accelerator) the sending of URLs to Google is intrinsic to the service. When you sign up for any such service, you will be informed clearly that the service sends URLs to Google, and whether and how you can opt-in or opt-out.
For example, when you submit information to a web page (such as a user login ID or registration information), the operator of that web site may embed that information including personal information into its URL (typically, after a question mark (?) in the URL). When the URL is transmitted to Google, our servers automatically store the URL, including any personal information that has been embedded after the question mark. Google does not exercise any control over these web sites or whether they embed personal information into URLs.
So does IE and I think Chrome does as well, in the case of IE its with user consent (do you want to help improve our products?).
Looks like the two approaches are completely different.
One doesn't require the user to have to buy/build any specialized hardware. The other doesn't require the user to rely on an external service.
The bitcoin world is big enough for both approaches to make sense at different times or to different people.
And I must say that after looking into actually implementing ECDSA on tiny hardware, I'm really, really warming to Gavin's idea.
One doesn't require the user to have to buy/build any specialized hardware. The other doesn't require the user to rely on an external service.
The bitcoin world is big enough for both approaches to make sense at different times or to different people.
And I must say that after looking into actually implementing ECDSA on tiny hardware, I'm really, really warming to Gavin's idea.
On a related note I found a commercially available smart card that supports the ECC curve bit coin uses and I have ordered samples, it provides a PKCS11 implementation which should be hook able into OpenSSL via it's engine interface. Its not the cards I though I would go with originally but they will work
1st step will be to get crypto to happen on the token, then the idea of getting a on device display for transaction or some other similar solution
http://www.athena-scs.com/product.asp?pid=33
The risk profile I care about is:
User's computer is completely compromised by a root-kit trojan, but they don't know it.
However, the user has access to some other device or service that they have setup in advance to be a "second line of defense" to prevent their entire wallet from being stolen.
User's computer is completely compromised by a root-kit trojan, but they don't know it.
However, the user has access to some other device or service that they have setup in advance to be a "second line of defense" to prevent their entire wallet from being stolen.
Right, so by definition they don't have their wallet on the computer. IronKey has built in AES encryption. Imagine a smartcard or usb drive that had built in ECDSA encryption. The device could generate and store private keys and sign bitcoin transactions, but would be designed to never allow access to the private keys. The client just sends the unsigned transaction to the device and gets back the signed transaction.
This still has an weakness though. A rootkit could send the drive a transaction for your entire balance and have it sign it. So you need a screen on the drive that shows the amount and recipient address, and a physical confirm button.
The Ironkey also does RSA, it can be thought of as several devices in one, flash, smart card reader, smart card, all off a single USB bus.
The scenario we discuss here though doesn't require the flash component though it is of course interesting for other reasons.
As for the trusted input problem there are a few solutions, it depends on how deep you want to go to solve it.
To protect against user mode key l loggers in windows you can use the session 0 ui to collect the pin, only kernel malware would get past that.
You could use a secure PED (hard to do in a decentralized system)
You can use graphical pins, random layout (kind of like captchas)
There are a ton, first step IMHO is getting the keys off the host
The risk profile I care about is:
User's computer is completely compromised by a root-kit trojan, but they don't know it.
However, the user has access to some other device or service that they have setup in advance to be a "second line of defense" to prevent their entire wallet from being stolen.
User's computer is completely compromised by a root-kit trojan, but they don't know it.
However, the user has access to some other device or service that they have setup in advance to be a "second line of defense" to prevent their entire wallet from being stolen.
Me too, and this is a likely attack in my opinion.
To protect against this attack one needs the keys to be in a crypto processor of some sort, and the ability to do some flavor of trusted pin presentment.
Though this would mitigate the risks significantly we would also want to have a recovery story in the event of token loss and theft.
I agree regarding risk profiles.
I known the iron key guys, it's a good product and the team they have is good but it's expensive and doesn't support ECC or at least it did not last year and I highly doubt it supports the curve bitcoin uses.
I think it would be possible to get the interesting scenarios to work on a cheap 10 device, initial probably being around 40 due to volume issues, the form factor doesn't need to be a card there are lots of USB dongles.
I known the iron key guys, it's a good product and the team they have is good but it's expensive and doesn't support ECC or at least it did not last year and I highly doubt it supports the curve bitcoin uses.
I think it would be possible to get the interesting scenarios to work on a cheap 10 device, initial probably being around 40 due to volume issues, the form factor doesn't need to be a card there are lots of USB dongles.
I have worked on systems that utilize key splitting in the past, though not with ECC.
I like key splitting but thought it might be worthwhile to play devils advocate and see where it takes us.
Usability of these systems are typically poor (complex and failure prone) but the nature of the systems that use this approach it's not been a problem, for Bitcoin I think it can be.
If the goal is to protect the key from compromise we might want to enumerate the threats we hope to mitigate, for example if it's the Trojan cases then the code that can steal one key could likely steal all keys.
Process and privlige separation helps address the key compromise cases, this can be done in a few ways for a software only solution you can imagine an authenticated service and a LPC or maybe one where crypto happens on a phone vs on the pc.
Another more common design pattern would be to move crypto to a smart card and have cards clone the crypto to a backup card to deal with the loss issue.
I like key splitting but thought it might be worthwhile to play devils advocate and see where it takes us.
Usability of these systems are typically poor (complex and failure prone) but the nature of the systems that use this approach it's not been a problem, for Bitcoin I think it can be.
If the goal is to protect the key from compromise we might want to enumerate the threats we hope to mitigate, for example if it's the Trojan cases then the code that can steal one key could likely steal all keys.
Process and privlige separation helps address the key compromise cases, this can be done in a few ways for a software only solution you can imagine an authenticated service and a LPC or maybe one where crypto happens on a phone vs on the pc.
Another more common design pattern would be to move crypto to a smart card and have cards clone the crypto to a backup card to deal with the loss issue.
I have a suggestion.
Part of why mag-stripe cards find more use than smart cards is because they are cheap and ubiquitous. Every merchant on the planet has some device already which scans mag-stripe cards and if they somehow don't (or use an embedded device) they can be had for less than $20.
When base-64 encoded, the public and private keys for a single wallet are plenty small enough to fit on the two tracks readable by most devices. Simply use a block cipher of some sort and a standard PIN number to secure the private key before burning to a card, write a little software to b64decode the keys and you're good to go. More merchants will accept a mag-stripe solution than a smartcard solution because it either uses hardware they already own OR it requires less expensive hardware.
You may also consider hacking together a small embedded device that handles all of this for the merchant and just needs a network connection. Once bitcoin gets ported to Android successfully you could easily write software for a smallish tablet like the Archos 7, which has a USB host adapter cable that allows keyboards and other HID compliant devices (like mag-stripe readers) to be attached. It's also fairly cheap in the $130-$150 range.
Merchants like easy, merchants like familiar, and merchants definitely like cheap. Give them something with a < $200 buy-in cost that will bring them niche business from the bitcoin folks that won't cost them monthly fees or steal a percentage of their profits and they will come in swarms. Make it convert to USD and deposit in Dwolla or such automatically and it'll be an even easier sell.
Part of why mag-stripe cards find more use than smart cards is because they are cheap and ubiquitous. Every merchant on the planet has some device already which scans mag-stripe cards and if they somehow don't (or use an embedded device) they can be had for less than $20.
When base-64 encoded, the public and private keys for a single wallet are plenty small enough to fit on the two tracks readable by most devices. Simply use a block cipher of some sort and a standard PIN number to secure the private key before burning to a card, write a little software to b64decode the keys and you're good to go. More merchants will accept a mag-stripe solution than a smartcard solution because it either uses hardware they already own OR it requires less expensive hardware.
You may also consider hacking together a small embedded device that handles all of this for the merchant and just needs a network connection. Once bitcoin gets ported to Android successfully you could easily write software for a smallish tablet like the Archos 7, which has a USB host adapter cable that allows keyboards and other HID compliant devices (like mag-stripe readers) to be attached. It's also fairly cheap in the $130-$150 range.
Merchants like easy, merchants like familiar, and merchants definitely like cheap. Give them something with a < $200 buy-in cost that will bring them niche business from the bitcoin folks that won't cost them monthly fees or steal a percentage of their profits and they will come in swarms. Make it convert to USD and deposit in Dwolla or such automatically and it'll be an even easier sell.
The problem with this approach is that every merchant "has" to steal your private key for it to work, even a honest host could screw up and keep a copy or if they infected they could be doing it for the bad guy without knowing it.
It's very possible build a secure variant wih cards being around 10 usd each if in reasonable volume with pos solutions ranging from 20 to 200 or so. Just have to design around commodity hw just not mag cards
Hey everyone,
Yesterday a few people from #bitcoin and myself decided to start an open source project with the aim of designing/producing a physical Bitcoin card, not unlike standard credit cards
The card would contain a separate wallet, which you could recharge from your computer.
Currently there are several proposals on the card concept, and the two most practical are :
1. Smartcard with custom software to support BitCoins
2. Custom hardware dongle/card with display and keypad for increased security
The other part of the project is the desktop-side software which would take care of backing up the cards wallet, and general management related to the BitCoinCard
Both approaches have their pros and cons
On the note that that the BitCoin is not ready for this type of usage, I agree, but it doesn't prevent us from starting on time, and have a solution when it's ready
You can follow and join the discussion here: http://groups.google.com/group/bitcoincard
Wiki (which is currenly unorganized and mostly empty): http://bitcoincard.wikispot.org/Front_Page
GitHub repository (also empty): https://github.com/ionspin/BitCoinCard
The project is just beginning, and any input and support will be appreciated!
Note to mods, as this is my first post, I can only post in the newbies section, so please move the topic to the appropriate session. Thanks!
Yesterday a few people from #bitcoin and myself decided to start an open source project with the aim of designing/producing a physical Bitcoin card, not unlike standard credit cards
The card would contain a separate wallet, which you could recharge from your computer.
Currently there are several proposals on the card concept, and the two most practical are :
1. Smartcard with custom software to support BitCoins
2. Custom hardware dongle/card with display and keypad for increased security
The other part of the project is the desktop-side software which would take care of backing up the cards wallet, and general management related to the BitCoinCard
Both approaches have their pros and cons
On the note that that the BitCoin is not ready for this type of usage, I agree, but it doesn't prevent us from starting on time, and have a solution when it's ready
You can follow and join the discussion here: http://groups.google.com/group/bitcoincard
Wiki (which is currenly unorganized and mostly empty): http://bitcoincard.wikispot.org/Front_Page
GitHub repository (also empty): https://github.com/ionspin/BitCoinCard
The project is just beginning, and any input and support will be appreciated!
Note to mods, as this is my first post, I can only post in the newbies section, so please move the topic to the appropriate session. Thanks!
Started a thread on a very similar concept see: http://forum.bitcoin.org/index.php?topic=20933.0;all
The exchanges should offer smart cards to secure account. If it is applied to a wallet that might be interesting.
I agree, with the crypto card approach additional cost for this for almost nothing.That's interesting. But consider making it a Bitcoin ready multipayment device. Let's say you can store credentials for credit/debit cards, with all kinds of fancy features that justify the price of the device, but that it so happens to be able to store Bitcoin transaction keys and the means to use them in a transaction with security appropriate for carrying around daily spending amounts. It could provide a back-door for Bitcoin spending from a device that people are already carrying around.
It is one thing to provide enough support for doing a transaction through a reader. Maybe this is setting the bar a little high, but what if there were a way to transfer between Bitcoin and other payment methods right on the card? Let's say you are where you can only pay with a Visa/MC but most of your funds are in BTC. You could make a transfer on the card from BTC to a Visa/MC balance and then make your pruchase. The merchant doesn't even need to know anything about Bitcoin. Perhaps it could be as seamless as a single transaction...
It is one thing to provide enough support for doing a transaction through a reader. Maybe this is setting the bar a little high, but what if there were a way to transfer between Bitcoin and other payment methods right on the card? Let's say you are where you can only pay with a Visa/MC but most of your funds are in BTC. You could make a transfer on the card from BTC to a Visa/MC balance and then make your pruchase. The merchant doesn't even need to know anything about Bitcoin. Perhaps it could be as seamless as a single transaction...
I don't disagree one however requires much more technical and business work than the other and while it would enable new scenarios in the mean time the platform risks still remain.
It may turn out that there is insufficient interest to justify even the most basic project which would still be a significant financial investment if one was to make it scale to the community in an economical and usable way.
My thinking was crawl, walk, run.
Get the keys and wallet-into a crypto device, move much of the client into such a device, build pos infrastructure and account scenarios.... You get the idea....
I should add that at least for us users it's trivial to encode the credit card data into a mag stripe on the back of the card but the issuers would through a hissy fit; in the eu this would be very problematic for technological reasons also.
That's interesting. But consider making it a Bitcoin ready multipayment device. Let's say you can store credentials for credit/debit cards, with all kinds of fancy features that justify the price of the device, but that it so happens to be able to store Bitcoin transaction keys and the means to use them in a transaction with security appropriate for carrying around daily spending amounts. It could provide a back-door for Bitcoin spending from a device that people are already carrying around.
It is one thing to provide enough support for doing a transaction through a reader. Maybe this is setting the bar a little high, but what if there were a way to transfer between Bitcoin and other payment methods right on the card? Let's say you are where you can only pay with a Visa/MC but most of your funds are in BTC. You could make a transfer on the card from BTC to a Visa/MC balance and then make your pruchase. The merchant doesn't even need to know anything about Bitcoin. Perhaps it could be as seamless as a single transaction...
It is one thing to provide enough support for doing a transaction through a reader. Maybe this is setting the bar a little high, but what if there were a way to transfer between Bitcoin and other payment methods right on the card? Let's say you are where you can only pay with a Visa/MC but most of your funds are in BTC. You could make a transfer on the card from BTC to a Visa/MC balance and then make your pruchase. The merchant doesn't even need to know anything about Bitcoin. Perhaps it could be as seamless as a single transaction...
I don't disagree one however requires much more technical and business work than the other and while it would enable new scenarios in the mean time the platform risks still remain.
It may turn out that there is insufficient interest to justify even the most basic project which would still be a significant financial investment if one was to make it scale to the community in an economical and usable way.
My thinking was crawl, walk, run.
Get the keys and wallet-into a crypto device, move much of the client into such a device, build pos infrastructure and account scenarios.... You get the idea....
I've been thinking about wallet security too. I think a second device is a good idea, but I see it working in a different way.
I see a portable dedicated device with very limited communications ability. Just a serial port will do, which probably means serial over USB or serial over bluetooth. It will also have a SD card socket for wallet backups.
The device will generate the key pairs, and store them. The private key never leaves the device, except on the SD card backup, which could be encrypted.
I think it only needs 3 hooks into the PC client software.
1) It needs to be able to push public keys to the client.
2) It needs to be able to ask for (and receive) balance updates from the client.
3) It needs to be able to accept an address from the client, and generate a complete transaction to that address using an amount entered on a keypad. (Or possibly accept an address and amount, then only ask for confirmation.)
I think this could help with the retail problem too; no reason why you couldn't plug it into a potentially hostile terminal.
I'm thinking Arduino. It should already have all of the crypto libraries necessary, plus hookups for serial, USB, BT, and SD cards. Probably going to order some hardware this week to get started.
I see a portable dedicated device with very limited communications ability. Just a serial port will do, which probably means serial over USB or serial over bluetooth. It will also have a SD card socket for wallet backups.
The device will generate the key pairs, and store them. The private key never leaves the device, except on the SD card backup, which could be encrypted.
I think it only needs 3 hooks into the PC client software.
1) It needs to be able to push public keys to the client.
2) It needs to be able to ask for (and receive) balance updates from the client.
3) It needs to be able to accept an address from the client, and generate a complete transaction to that address using an amount entered on a keypad. (Or possibly accept an address and amount, then only ask for confirmation.)
I think this could help with the retail problem too; no reason why you couldn't plug it into a potentially hostile terminal.
I'm thinking Arduino. It should already have all of the crypto libraries necessary, plus hookups for serial, USB, BT, and SD cards. Probably going to order some hardware this week to get started.
I started with the assumption that my box is owned, and every retail terminal is owned (which is true, since they are literally owned by someone other than me).
You plug into your home computer or a retail POS, and the computer sends a payment request. The device displays the address and amount, you press yes or no. The device then generates a transaction, or doesn't.
Point 4 through 6 are unnecessary in this scenario, since I'm not worried (yet) about the device getting lost or stolen. The only problem I'm looking to solve right now is the malware stealing your keys problem.
Ah, you started with the retail terminal scenario; I started with the scenarios in use today thinking it could be expanded to those if the cost could get down low enough.
If I were to start with the terminal scenario I would have still do a smart card for form factor and cost reasons; implementation wise I would do a custom card applet that implements the bit coin wallet, communicated with a secured pin entry device (ped) or had onboard display and input mechanisms.
The approach you mention would work but I don't know if it could ever be scaled out to a currency card in a cost effective manner.
That said our two lines of thinking are compatible.
I've started working on such a project, but it won't be a card, at least not the early models. Only items 1 through 3 in your list are really critical here, at least to start. Also, a display built into the unit is absolutely critical. Without it, there can be no security at all.
I wanted to add that 4 is also very important, the next malware will just do transactions vs steal keys without it.
I've started working on such a project, but it won't be a card, at least not the early models. Only items 1 through 3 in your list are really critical here, at least to start. Also, a display built into the unit is absolutely critical. Without it, there can be no security at all.
Interesting, I would be interested in knowing more if you would be willing to share; as for your display statement could you elaborate on the assumptions around that
You have to pay more for "secure display" capabilities but such devices do exist.
Well now that might work - if it can show the amount of the transaction before it signs it.
Then again most everyone these days carries a mobile phone, so a phone + near field communication is probably the more "killer app".
Yes this is another natural evolution of such a solution, I have worked on several "virtual" smart cards in my career some of which use phones. That said right now the phone doesn't offer great security,just consider all major phone platforms now have malware variants of their own.
This approach, at least today also doesn't provide the same mitigations, they can be thought of more as a portable flash drive; though to be fair Much of the value of a smart card is getting the keys off the host and these virtual smart cards can have that property. Developing one of these, at least one with reasonable usability and security properties requires platform work from the phone vendors that has not been done.
.... unless I'm mistaken they don't make smartcards with neat little screens on them. 
You have to pay more for "secure display" capabilities but such devices do exist.
Yes they do, and it's possible to build systems where the card authenticates the reader cryptographically but such systems would require a arbitrator like Visa which philosophically may be hard to swallow in the BTC community. That said my interests are shorter term
The form factor would be very interesting. Having some kind of card implementation of wallet storage would be highly desireable. (At least, speaking for myself.) I would have to do more research on what would be required to get some kind of smartcard system going.
As far as form factor I thought fob would be more interesting at first in that there is not a need to cary a reader around when you want to use your wallet. That said the technical implementation is the same, it's a packaging question.There would be some technical changes necessary to things like the wallet file for example it would need to be able to contain references to private keys in addition to containing them but My goal with this thread was to gauge interest, and float price as part of that.
Heck, how about a bitcoin ATM that really is just a secure linux implementation that assigns coins to your card based on currency deposits?
As for the ATM thing, on the surface it seams that the transactions of Bitcoin transaction prevent their use in a ATM like transaction without an intermediary making some sort of guarantee on the transaction. I can of course imagine that longer term but it's only viable in this model if the technical infrastructure is put into place and people are wiling to pay