Bitcoin Forum
May 21, 2024, 10:07:09 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Methods to against Man in the Browser (MitB) Attack.  (Read 1433 times)
twolifeinexile (OP)
Full Member
***
Offline Offline

Activity: 154
Merit: 100



View Profile
February 15, 2013, 07:58:33 PM
 #1

  My thoughts on this topic originated from discussion with Puppet over a thread about lost bitcoins  on Mt GOX, I mentioned using 2-factor authentication against key-loggers and puppet's counter-argues if attacker mimic the browser behavior and stole one-time password and immediately logged on using that one time passcode and use that as a way to steal bitcoins/bank money.

How much security does Yubi key really add if your PC is compromised?
Im not sure I fully understand this; if the attacker has root access to my PC, he can show me whatever he wants, and send something else to Mt Gox. All he would have to do is wait for me to do whatever transaction that requires the yubi key, provide Mt gox with a different transaction instead, show me the challenge for that fraudulent transaction and make me confirm it.
Im no expert, never used mtgox or yubi key,  but what am I missing?

  Even though I think Puppet is over-downloooked 2 factor, it is indeed not immune this type of Man in the Browser attack. So what kind of security protocol could be utilized against this? I know some people use "hardened" client, like load whole OS from read-only media, but that make the whole process too painful.
  So I am thinking of a two-factor integrity check method, and I am using google-authenticator as a example here: Say you have send a request to server a withdrawal request, then server package the request info, generate some QRCode/hashes regarding this request package , then this hash/QRCode is asked to put into your 2-Factor processor which then use a Timed based one-time password to rehash this info to produce a specific one-time-transaction-specific-code, in the meantime, present a transaction  summary to you. ( So if the attacker changed the request you can spot)
  You use this final generated one-time-transaction-specific-code to authorize the transaction.
  From my view, this way is immune to man in the browser attack and the final implementation could be very easy, like google authenticator could take a photo of the QRCode from screen and generate transaction summary and one time password in one step.
 

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!