No, its not a security issue, a DoS exploit in noncritical client software is not a concern, as long as you need to stay at the malicious webpage for it to DoS.
For example, if a malicious JavaScript code could DoS at arbitary times, it can be fatal if you manage it to DoS in the middle of a webshop transaction, leaving you without funds and with unpaid status on your Products.

But now, its not at arbitary times, its only when you stay at the malicious page, and on top of that, each tab is sandboxed. So the page can essentially only DoS out the user from itself, in other Words, no security concern at all.

DoS in server software is a entirely Another chapter.


So using this "exploit" in a intentional matter is not fatal at all, all they can do is crash the browser... fine with that, that makes you exit the malicious webpage.
So this bug is not a concern for security - as long as the webbrowser is not part of a critical system where its not allowed to be exited or crashed.

Why do you blame IE & Microsoft? Its only bitcoin forum currently who crash IE10, the latest.
Its a bug in the JavaScript.

Since the crash appear when you change page, it might have anything to do with OnUnload or OnBeforeUnload event on this webpage.

Randomly, when browsing bitcoin forum, it crash IE 10 with this dialog:



Message: "Internet Explorer has stopped working. Windows is searching for a solution on the problem".
After a while, the page reloads and say


"A problem with the website made Internet Explorer to reload the tab".

Maybe some admin could fix this website problem?

Version: latest - 10.0.9200.16521

Once its manufactred, its loaded keys are uncopiable.

Note that you can load any keys in Yubikey, so the things are essentially manufactred empty - and then loaded with keys at Yubikey manufacturer plant.
They can be reloaded as said with any keys, making the manufacturer plant IMPOSSIBLY know any keys. Also they contain no backdoors.

So essentially, its impossible to extract the AES key out of the device. This means that you cannot manufacture a new device that exhibits same behaviour as the old, since you need to know the AES key for that.

Would say Yubikey.

Reason: Google Authenticator is a softtoken. This means that it can easy be duplicated with anyone that has physical access to the token. With that, I say that screen lock on the phone is NOT enough, since content is not encrypted. Encrypting the phone and TURNING OFF the phone EVERYTIME you leave it behind will work. However, if someone was to sniff or figure out the encryption password will still be able to duplicate token without you noticing.
Note that copyng the token means copying the secret HMAC key stored in the android files, NOT simply copying token codes.

A problem is also that its a time-based token and not a event-based token. This means you will not notice if someone has unauthorizely used codes from a copied token, since both tokens will be roughtly in sync.

A event-based token will however desync if a code from a copied token is used, so your own codes will struggle. Also, its easy to detect unauthorized usage and infer a action, like locking the account until the key in the token has been refreshed via a secure means of authentication.

In other ways, as soon as you leave the phone in a unsupervised space for even a couple of minutes - you need to regard the phone as "compromised".

-------------------------------------------------

A yubikey however, is a hardtoken which is event-based. This gives both singularity and security against copied codes. Also theres additional security in Yubikey: A clock that is started on powerup and stopped at powerdown, which pretty presicely measures the time lapsed between 2 generated codes. This means the server can verify that the codes was presented with roughtly same interval as they was generated, which means its almost impossible to use codes copied into a notepad document and then used later.

The good with singularity is short of this: You can put the token on a bench on Metro Station, then wait a couple of months, and then come back and take the token, and still be secure. (Of course, somebody could have used token while it was lost, but once you have it again, you can be sure its secure since the token is UNCOPIABLE)
Its like car keys: You lend out the car and give the car keys to the lender.
Once you take back car keys you can be sure nobody else than you can open your car.

This also means a great possibility to give out temporarly access without risking somebody copying that access and storing it indefinitely.
Eg: You lend out a account with 1BTC on. You can later be sure that when you have got back the YubiKey and then fill the account with
10 000 BTC, you can be sure that the person that lended your youbikey CANNOT technically hold a copy of it.

So basically, once you program Yubikey with a AES key, it can never be retrieved, only overwritten.


-------------------------------------------------

A google authenticator token can be made secure by using a secure mobile micro-SD card with a built-in smartcard chip, that
can used to protect the HMAC secret. Then you get both the simplicity in having the token in a device you always have with you, and
the security in that the token is uncopyable since the secure smart-card microSD will not allow the HMAC key leave the card, only
give a access code that match a time.
If the microSD card also contains a secure clock, it can prevent codes from generated to the future.

I understand what the OP is out after:

In RSA, theres something called blind signing.

RSA is:
Applying the PRIVKEY to a plaintext, the resulting chipertext can only be decrypted by applying the PUBKEY to the text.
Applying the PUBKEY to a plaintext, the resulting chipertext can only be decrypted by applying the PRIVKEY to the text.

Then blind signing is applying a factor X to a key, so the signer does not know the contents of the message.
If the message is M*X, the signature is S*X provided that S is a signature of M.

If E is a encrypted message encrypted with keypair consisting of PUB A and PRIV B it will be:
Apply A to P and gain E.
a adversiary can fool the receiver to decrypt the message as:
E*X.
Send to owner of B.
Owner applies B to E*X and yeld P*X.
Adversiary removed X by dividing P*X with X, and yelds the plaintext P.
More info: http://en.wikipedia.org/wiki/Blind_signature



The OP wonders if there is similiar risk with signing a adress with its own key and risking leaking the key or something.

Can say that since the adress is a hash of the pubkey, its NO risk whatsoever to sign the adress.
There MIGHT be riskes with signing public/private keys, but I don't know enough about ECDSA to prove it false or true.

aha now I understand.
But you talked about having some "bypass" or "override" of the builtin rules.

What about a physical button that needs to be held down? So if you are going to do a tx that would violate the BSM rules, you have to be physically present at the BSM and hold down the button while doing the tx, and then release button. And of course it would only allow one tx per button press.

DAT: But as I said the site operator "initalizes" the HSM by helding the pushbutton and then feeding it with the 6 latest blocks.
After releasing pushbutton, the HSM will never accept a block which isn't "valid" according to the previous block hash and PoW.

So the hacker, despite having full control, cannot feed "false" blocks to the HSM since the block needs to be "tied" to the latest block.
Only way would be for attacker to redo the PoW, but that would take too long time.
Supressing any blocks would only be negative for the attacker, since a incoming balance would not be reflected on a user account and the user has access to less funds to steal.


Maybe it could store the userIDs to the 6 latest block temporarly in memory, and only updating randomvalue and returning blob upon receiving 6 confirmations?

So basically:
1: Host feeds blockA to HSM
2: Host feeds BlobA to HSM
3: Host feeds BlobB to HSM
4: HSM stores these userIDs along with how much the balance should be increased.
5: Host feeds blockB to HSM
6 ...*...
and so on
.....
.....
20: Host feeds blockG to HSM.
21: Host sends BlobA to HSM (again).
22: Host sends BlobB to HSM (again).
23: HSM returns updated BlobA to Host
24: HSM returns updated BlobB to Host


To "fool" the HSM, the attacker would need to compute 6 sequental fake blocks and send to HSM. Note that the HSM throws away the block once all required data is extracted, and only saves the 6 latest hashes, so the HSM would only need to store one single block in memory + 6 hashes in flash. Since the balance is stored in blobs, the HSM does NOT need the whole blockchain.

PoW of 6 blocks is really challenging for a attacker to create.

galambo: Or what about a raspberry Pi?
The Raspberry Pi could BE the HSM actually, and have a hardened OS on the SD card. Theres space on the board to mount a extra physical button that will affect one of the GPIO's that will make the HSM to bypass almost all security checks while its depressed.

like if (sha512($suppliedpassword) == $userhash || $GPIO16 == true) then

end if

The OS could be built by the bitcoin community and be freely downloadable as a image, that then can be dd'ed to a SD card. And SD card size then tells how many users it can store.

There is serial connections on the board, else a simple USB null modem serial cable (a cable with 2 USB males and a fat thing in the middle containing rs232 electronics) could be used to connect the raspberry to the host.
since the rs232 interface is well defined, there would be no possibility to "hack" the system.

DeathAndTaxes: Lets spin off of the idea and improve it then.

We could have encrypted storage outside of HSM in this way:
All accounts are stored OUTSIDE of HSM, but encrypted with a key ONLY the HSM knows. Lets call this encrypted chunk of data for a "blob". This "blob" are stored in the user's row at the site database.

Then each time a account needs to be used, its fed to the HSM and the HSM updates the account and returns the encrypted account blob.

BUT we need some way to verify we are not using a "old" encrypted blob with a "old" balance. I got a idea: Let each account have a n-bit ID. Each encrypted blob contains the ID and a small random value.
The random value is stored inside the encrypted blob along with ID.

Each time anything in the encrypted blob is updated, the new encrypted blob will have a new random value. (but same ID).
the HSM will NOT accept a encrypted blob containing a unmatching random value.

User's private keys and such can be stored in this blob too.

The random value and ID is stored in internal HSM memory. Lets say a 14 bit ID and a 18 bit Random.
14 bit ID will account for 16384 users.
Each user will "use up" 4 bytes
That will be a total of 64KB internal flash memory used.

And you would need 262 144 transactions on a SINGLE USER before random numbers start to repeat. And that would only allow a attacker to duplicate a balance ONCE. A simple cooldown between each command sent to HSM with lets say 1-2 seconds would slow down the attacker considerably.
Duplicating the balance would require this from attacker: Send a small transaction using blob1. Receive blob2 from HSM. Send blobOLD and see if the HSM accept it. Send a small transaction using blob2. Receive blob3 from HSM. Send blobOLD and see if accept. Send transaction using blob3 and receive blobN from HSM and so on and so on.

A cooldown of 2 seconds between each command would require 6 days work from a attacker before the attacker MAY succeed, and before 6 days, a attack would be guranteed noticed.



>>"If we assume the attacker has complete control of the host they could simply record a fake deposit and then request a withdrawal."
Nope.
The HSM should of course require you to feed it valid blocks. You feed it blocks as soon as you find it on the bitcoin network, and the device saves 6 blocks by hash in "flash" and saves the whole latest block in RAM while updating balances. After the host have indicated its done with feeding blobs, the block will be deleted from RAM.

The Host would need to keep track of which users to feed to the HSM for balance updating when it receives a payment block for one of it user's adresses.
So for it to INCREASE balance, it would need the attacker to actually depoist money into a user's account.

So the host does this when it sees a block paying lets say BitCoinUSER on Bitcoinia:
Host sends the block to HSM. HSM processes the block, and now it expects a blob to update.
The host now replies with the blob corresponding to BitCoinUSER.
HSM decrypts blob, increases balance and random value, reencrypts it, return to the host.
host saves this new blob in the database row for BitCoinUSER.

Host can indicate to HSM if the host has more blobs to feed, for example if transaction have multiple outputs pointing to a single user each.
Or if a block is totally unrelated to the site in question, the host can indicate like "0 blobs to feed".


So the encrypted blob (ONLY decryptable by HSM) would then contain:
Username - Hashed password - Balance - Receiving address - UserPrivate Key - UserID - Random Nonce

And the host database would then contain:
Username - Hashed password - Balance - Receiving address - (some other details) - Latest encrypted blob from HSM.

Note that the host database now contains the username, hashedpassword, balance, recv adress 2 times, one in plaintext format and one in encrypted format. The plaintext format is so the site can itself verify balance and other details before bothering the HSM. Of course the plaintext values is not sent to HSM and does not affect HSM in any way.

A depoist of for example USD --> BTC would then require manual intervention by site operator.
But BTC --> USD would then be direct.
This are also inline with site's policies, since a site WILL want to verify a USD depoist really hard before sending bitcoins, because a USD depoist may be chargebacked.


rjk: Of course the blocks is fed by the serial port, and not via the internet.



OVERRIDE IDEA:
You are talking about a 128bit/256bit key. Not needed at all.
Simply have a momentarly pushbutton on the HSM. This button needs to be physically held down while loading new "rules" or overriding rules.
A attacker who "pwned" a server online cannot reach the physical button and cannot bypass the HSM.


But the problem with "rules" is that a user owning a 1000 BTC account may not be able to use his account fully without a site operator having to confirm transactions.
We need some way to store/process indivual users in the system in some way, so a user owning 1 BTC will only be able to send 1 BTC, a user owning 1000 BTC will only be able to send 1000 BTC.

Would suggest 2 modes instead:

1: Retailer/end user mode: The device will require a momentarly physical button to be held down for it to sign a outgoing tx. If a attempt is made to sign a tx without button held down, it will disconnect USB interface and beep each Xth second. (Xth second needs to be carefully selected so its not annoying, but its "hey someone is trying to steal your funds").
To reset, the user needs to disconnect the device and reconnect.
There should not be able to discern if the physical button is being pressed or not, from the USB interface, before its "too late", so a trojan cannot wait until the button is being pressed and "piggyback" that.
It will only sign one TX for each button press, for sending multiple TX, you would need to release the button and press again.

-----

2: Exchange/onlinewallet mode:
The device will keep a database of users, hashed password, their balance, and their receiving adress.
The device will NOT sign a TX that would cause a user's balance to go negative.
Along with a TX to it for sign, the requestor needs to supply a username/password of whoever's account to use.

The device also needs someway to verify incoming funds. So the device in some way needs to know the blockchain, or some other way to verify that a incoming funds is real, and then populate the user's balance, then automatically "sweep" this adress to the exchange/onlinewallet's main adress/hot wallet, then delete privkey and adress from user storage. Will also send out signed transactions for the host to just send out on the network. (sweep transactions)

It does not need to save the whole blockchain, the device would only need to save the 6 last blocks, because when it have seen a transaction and populated that user's balance with the money, the block is no longer needed for the device in question.

There also needs to be meta functions:
create account - creates account with 0 balance
delete account - deletes account if correct password is specifyed, but ONLY if the balance is exactly 0.
change password - changes password of a user.
update user balance - Can be used to deduct money from user, but not add.

The physical button will in this case function for password reset. While its held down, the device will accept any "old" password for changing password on a user (and not just the correct password). So basically, if a end user forgot his onlinewallet/exchange password, this would require manual intervention, where the site operator initiates a password reset, then physically are present at the HSM to hold down the button and then completes password reset, then gives the new password to the end user.

The physical button held down will also make the device accept any TX without any user, and this is when site operator collects fees from the main wallet.
The physical button also needs to be held down for it to register a "checkpoint" block, which will be required during initalization.
The physical button held down will also allow "update user balance" to add funds.


The security in this is: Lets say bitcoinica case.

Lets say bitcoinica consist of 180 users with 100 BTC in each wallet. The HSM device will then have a "hot wallet" (one address) of 18 000 BTC and 180 users inside.
A hacker that hacks into bitcoinica server, will not know any user's password because they are hashed at the site database. The hacker needs to crack these to get the unhashed password to authenticate to the HSM with. Lets say the hacker manages to crack 5 users.
The hacker will now use password for user 1. He now tries to get the HSM to sign a transaction for 18 000 BTC. But the device sees "the hot wallet contains 18 000 BTC but user 1 only have a share of these of 100 BTC" and will reject the transaction.
The hacker only have the choice of signing a sum of under 100 BTC.
So in this case, he would only be able to steal 500 BTC (5 users with 100 BTC in their account each)

For the hacker to be able to push larger transactions, he would need to crack a user that have depoisted a large sum at the exchange/onlinewallet service. And users with large BTC sums tend to have secure passwords = fail for the hacker.


So basically, the device would accept a 10 000 BTC transaction, ONLY if the user that is specifyed in the signing request, have 10 000 BTC in his account.




-----

Basically this would solve everything without delays for end users and without manual intervention at "correct" large transactions.
The "password" used to authenticate at the HSM for a specific end user can be anything, a encrypted string or whatever, even a expected "reply" from a security token or whatever.




NOTE: Dont misunderstand this now. With "balance", I DONT mean the wallet balance at the end user. I mean the balance the user have in a "virtual" account at the online exchange or online wallet service. This are NOT a actual bitcoin wallet balance, its just a stored-value of whatever a end user can spend at that site.

Clicking the ads, sometimes it render the error "A error with the tab caused Internet Explorer to close and open the tab again".
Just click on the ads for a looong time, lets say 100 different clicks.
The error appear random.

are you gonna fix the IE9 crash or not?

Yep, the sticker are "tamper resistant" so it should be hard to remove the sticker without leaving traces that the stickers have been swapped.

And the GPU has a serial number, and if suspect, I think they would compare their records of the GPU serial with the card serial.
And what do you do when the newer cards fail after those 2 weeks? Then you don't have any sticker to swap with?
(you cannot use the "replacement cards" sticker, since these stickers have then expired*)

* Think of you have 2 weeks left of warranty. When replacing, your warranty is NOT renewed, rather they set the serial number to have 2 week left of warranty. When the newer cards fail, those 2 weeks are out. When the replaced cards fail after 1 year from replacing them, your warranty is like 2 years old and expired.

The cards propably log runtime too, so they can see in a log how much time the card have been "on". Propably the card logs full-load time too. So then they can see that the cards have ben run for longer than manufacturer date and that would raise some alarms.

Propably, the Sapphires 5850's are tuned to work flawlessly under full load until end of warranty (1yr) + a few days, to keep the parts cost down. Half load = 2 yr + a bunch of days.
25% load = 4 yr + 1 month
and so on. Since they don't expect people to game under full load 24/7 (which you would basically "do" if you mine with the cards, from the card's point of view), they don't expect the card to fail after 1 year.


If they find out what they do, you would be charged with fraud. You cannot expect the card to work after 1 year (when the warranty expired) so just pull up your wallet and buy a new card!

I don't understand the Example 1 here:
https://en.bitcoin.it/wiki/Contracts

What would prevent a spammer from getting the money back? Since if the site says he will not allow a early closure of contract, still the contract will expire after (in the example) 6 months of time and the spammer/abusive user will get the coins back...

Basically, we want that the website cannot earn from the contract (if not the user agree to it), and the user will lose from abusiveness, and that theres some automatic "failsafe" in case the website shut down.


** -- Idea Exchange -- **

So basically, for this scheme to work, the website would need some sort of "kill switch" that will spend the coins to a adress which can be proven it does not exist any private key to (or a verifiable charity), which does not require the user's signature. Eg, the contract need to be able to end up in four different states:

1: User & website agree to: Coins coming back to user.
2: User & website agree to: Contract is renewed.
3: Only website needs to agree: Coins are "killed" (or pushed to charity).
4: Contract expires, none need to agree: Coins coming back to user.

(the fifth state - coins go to website - is not useful in this case and is left out).


So lets take some examples:
1: User wants to end the account early. Then the contract is ended early by both the user & website and coins returned.
2: User wants to continue his account. Then the contract is renewed.
3: User is abusive. The website pushes the "kill" button causing the coins to be unspendable. Theres no incentive for the website to push the "kill" button if the user is not abusive, since the website will not earn anything from pushing the "kill" button.
4: The website shut down. Since the "kill" button was not pressed, the contract will automatically expire and user gets his coins back.


But how could such a "kill switch" be implemented in bitcoin terms? The kill switch must be pushable without the user agreeing to it, and both the website and user need to be sure the adress in question ends up nowhere (or a verifiable charity).

Would suggest that you at least try to resolve and/or connect to the URL before allowing it through.
Someone has set up a ad for "Gold Game Land" that points to http://www.your-ad-url.com/
Also remove the default and only prefill the field with http://
It could be easy, just "GET" the ad URL with wget/curl/LWP::UserAgent with a timeout of 3 seconds and then make sure you get a 200 back. If not, then the URL is invalid.

And STILL it crash IE9 sometimes by clicking the ads.

Kettenmonster: I know what you mean, you suspect the 1BPK adress is mine but thats not true, just verify with the thread linked that Luke-Jr written and you will see that the adress I specifyed match with that thread.

check_status: I don't see where the "vanity" in the adress is.

Sukrim: Then you simply send all coins in your donation adress to 1BPKHoL1sAVnfzxnH38RfXYYcHrEcniUKW
Thats a special recovery adress set up for those that received stolen funds.
Sending all your coins in your donation adress to 1BPKHoL1sAVnfzxnH38RfXYYcHrEcniUKW will then "clear" your bad reputation so it will not affect you in the future.

You can check the transaction history on blockchainexplorer and check if the coins can be tracked back to the adress 18***yiczhXSSCTciVujNRkkMw1zQ***hp (Scammer's adress), then your coins are black and its just to send everything to 1BPKHoL1sAVnfzxnH38RfXYYcHrEcniUKW .

(putted *** in the adress to prevent it to be sent coins to by mistake)


Why you sould care? Yes because these coins do NOT belong to bitcoinica, rather their userbase, eg those using bitcoinica. Its not a "blame on yourself" type of thing, since the end users could not do anything to prevent this. And bitcoinica will not itself win or lose something on recovering the funds, rather than their reputation would be good if they recovered all the funds to its users.

Your site crash my browser.
Clicking a ad, does completely crash the browser to desktop.

using:
IE 9.0.8112.16421
UA:
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)