Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics - page 56. (Read 482537 times)

I doubt these help, as the attacker doesn't seem to be using blockchain.info software to attack.  They seem to get the private keys somehow.

In the light of recent mysterious stealing of coins despite having 2FA and double password, will it be possible to offer any more protection against withdrawal ? Few suggestions in addition to the existing ones (of course the user will have to enable these, and not default):

1. A email reconfirmation (with hotlink to be clicked) before withdrawal. No reconfirmation, no withdrawal processed.
2. Option to completely disable withdrawal with a radio button / option, for which enabling withdrawal is email hot link confirmation dependent (like #1)
3. A picture + phrase verification while logging in with (alike Bank of America etc.)

Any other suggestions welcome.

Whew.... 

Thanks for clearing that up. I was beginning to get worried that they site was compromised.

Apologies this was a problem cause by me. The error should be fixed now if you reload the page a few times.

Also please remove the verifier and use one of the packaged browser extensions http://blockchain.info/wallet/chrome-extension

HELP!!!

Everytime I go to my wallet page I get notified that an illegal imbedded object has been found and the popup states that I should not continue!!

WTF is going on with blockchain.info?

Well that sounds like a suboptimal setup then?

Just getting a white void below "Wallet Home   My Transactions    Send Money    Receive Money    Import / Export" tabs... no way to log in, and clicking those tabs does nothing.

That's with Javascript disabled. With it enabled, it's exactly the same, but a warning flashes up "For security reasons please disable Java".

From what I understand this password is used by the device to access your account.  Having the hash of the password would not help the device access the account.

Why not do the standard / obvious thing?  You must have SHA256 in the code already.  So rather than storing plaintext password, store SHA256(password)?  Plaintext should never be stored, always (salted) hashes.

Thanks for replying to the feedback - much appreciated!


Could you explain a bit more about how this works? At one point exactly does 2FA get checked? Before the encrypted wallet is sent to the browser?


I appreciate a one-time-alias is work, I'd be willing to contribute towards a bounty for this. Perhaps as an interim you could offer browser-always-authenticates as a per-account option?


How about no passwords are stored but the user chooses which private keys are available on Android? I'd be happy to have a special wallet with only a few coins for use on Android, and read-only views of the rest of my balances.

Android OS protects each app's data, so unless your phone is rooted, you're not going to be able to access this file.  The only way to access it on a non-rooted device is to use the android toolchain to backup your phone e.g.


don't do this, by the way - storing your keys or a method of getting to your keys on more devices (even inside an encrypted backup) is a really bad idea.

Will

Can you tell us the file paths?  I would like to do some testing to see if/when  I can access it (phone locked, unlocked, etc).

Yes, for the app, and yes that would be great. I mean it's pretty unacceptable to have the choice of either no fee or 0.005 fee when sending 0.007BTC..

The last 50 backups are kept, so if you update the wallet 50 times old ones will start getting removed. However If you are deleting the key for security reasons you should assume the backup is kept for ever and instead use a new private key generated offline.


This should be fixed now, you may need to clear your cache.


For the android app? A number of people have requested this, my opinion is with the mobile app you want to send as quickly and easily as possible and so should need to alter the fee. I'm sure I can add a settings option for it but I don't want to add it to the send form.


The transaction is larger than standard, it has calculated 0.0005 BTC per KB and rounded up. (see fee changes below).


It assumes it is at least semi secure but you of course still need the password(s) and 2FA details to actually login. 2FA should be sufficient but not everyone has it enabled, this is mandatory.


This is possible but would take a fair bit of restructuring. Might be better to require every browser to authenticate themselves via email even if they have access to the identifier, depends how annoying it gets have to respond to all the Authorise login attempt emails.



Fix now thanks Stephen, same with the other bug regarding the corrupted transaction.


Yes the main passwords on both mobile apps are stored plain text but sandboxed. If the phone is rooted malicious apps will able to break the sandbox and read the password.

The second password is stored in memory while the app is running but never saved locally.

Possible solutions are:

1) Never remember the password. Depending on how long the password is it would get extremely annoying having to type it in every time the app is launched.
2) Encrypt/Obfuscate the password with information stored locally. Solves the shock factor of "Ah my password is in plain text" but would be easily circumvented by anyone with technical knowhow.
3) Pin protection with server side help. A random password is generated when the app is installed the user's password is encrypted with this and uploaded to blockchain.info. The encrypted password can then be retrieved from blockchain.info by providing a pin and decrypted locally. It is a decent solution but at the moment the users password is never uploaded to blockchain in any form and this violates that rule.

Feedback appreciated.


-------

Changes

- When the transaction fee policy is set to "Frugal" in account settings the base fee has been lowered to 0.0001 BTC.
- There is now the ability to block TOR exit nodes from accessing a wallet. If you are a TOR user you can of course continue to use your wallet without problem but don't enable this option.
- Double encryption now supports any custom defined number of pbkdf2 rounds. However there is no option to adjust this yet as when the rounds are increased over 1000 there is significant noticeable lag when decrypting the wallet and creating transactions, the decryption routines need to be made none blocking with a progress indicator.


 

Even encrypting it with a static key would be (slightly) better.

Yes, but in plaintext? Are there no better options?

I am also seeing this behavior.  Tested from a completely fresh IP/browser/computer in incognito mode with all local storage/cookies deleted

Will

I'm not sure this is working.  On a new browser with no cookies or other local storage (Chrome in icognito mode) I enter my alias for Identifier.  The page is reloaded and the ID field remains blank.  Then in another tab I go to Blockchain.info/wallet and there is my identifier.   So the challenge is defeated somehow.

it should be no surprise that the blockchain apps store credentials to access your wallet on the mobile device ... how else would you be able to view the wallet and make payments?

Piuk, the developer, makes the perfectly reasonable assumption that if he stores the data in the OS recommended storage mechanism (for android, this is /data/data/ location, which is only readable by the app) then that should be safe.  If people go ahead and install custom ROMs (with publically available signing keys!), backing up their data using Titanium Backup to their sdcard (readable by any app), or running apps that request root, then they are taking the risk that the files will be read and used to access the wallet - just as if you installed some random stuff on your PC and then used bitcoin-qt to decrypt your wallet, you would be at risk.

My recommendations stand, that you should use a very long, unique, passphrase, turn on 2FA.  If you feel that your keys have been compromised in the past by using the app on a rooted device, or backing up your keys somewhere that might have been compromised (e.g. the email containing your aes file) then I recommend setting up a new wallet with a secure passphrase and 2FA and sending all your coins there.

Will

Well i have an iPhone so that would be why I couldn't find it  

I am pretty sure that the iPhone version uses the keychain, which should be sufficiently strong.

EDIT:  This post: http://www.reddit.com/r/Bitcoin/comments/1czrua/just_lost_160_btc_from_address_managed_with/c9luqfy claims that the plist is stored at /var/mobile/Library/Preferences/com.rainydayapps.Blockchain.plist although that file does not exist on my device :/ so who knows.