Hi Martin, >first of all I haven't been following this thread from the beginning so I >haven't read all of it yet. However I see that you mentioned the security of >banks using the 'calculators'. I think it's a very interesting system, and ... >to the system. Since the challenge data is different each time and the >device salts (correct expression?) using a incremental (time) value, a Exactly. The only 'acceptable' solution, how to keep my secret key private I found, is to put it into small external hardware device, which 'sign/autentificate' some string/datas.... Doesn't care if it will be calculator (user type letters), or small USB/COM device (java script/small program/ActiveX/... communicating over simple protocol). Important is, that device 'signs' - it never sends keys itselfs. >response can only be used once. This makes sniffing of passwords anywhere >unusable. Of course, once you've logged in, the browser uses a session >cookie to make sure you stay logged in until you log out, or time out. This >is where the second use of the device come in. To make transactions you have >to sign both account numbers and sums using the device. This makes stealing >sessions (which is made harder due to https) useful only for read access. Exactly. >1.Man in the middle attack which feeds wrong sums/account numbers to the >user. Which would need a user that doesn't realise that the numbers that >come back doesn't match the ones requested. For high security layer, verification string should be depenend on HTTP address/datas/.... Something like this: I need to transfer money to account ABC, then my auth reply will be based also on this account, and I will have to verify before 'send' to bank (after fill form, it will verify ...). So, I will put into calculator server auth string, destination account (or similar). Then no-one can 'change' destination account (which will transfer money to his own one). Or at least, verry hard let's say. Or server auth string will be combined from accounts/time/.... (its hash if too long) and enctypted by private key. Calculator will decrypt, sign with different private key (or the same, doesn't care).... Then communication will be without any trouble 'plain' (and man-in-middle-attack can do nothing at all). But we can't use this scheme, because our application is not 'chunk' based like bank transfers... We have to use different way. Server sends all auth strings in encypted form. Man-in-the-middle-attack will get encyrpted auth string. He can't see 'inside' -> what server "asks" for. Should be hard to change without known my private key (actually, 2 keys - both 1024 bits). Time is involved, so, auth will never 'repeat'... Major problem with this attack is stoling 'communication itselfs' (which is over SSL) after auth were sucesfully done (stole sessionid/cookie/...)..... I though about some sort of 'sum' for every address. Every address (http://www.server.com/somewhere...) and form will also get its hash sum combined with secret key. But implementing into browsers is not easy (requires ActiveX or small external program which "hacks" browser interfaces... And not all browser should allow this autmaticky.. But maybe JAVA way is possible... Solution for IE is easy - but we don't want be IE only). If this will be done on server side, it will not help. It will only scare user in some cases (when he clicks twice on link, etc.). I didn't find any good solution for this trouble yet :( All products I saw were possible to hack this way (including my bank inet-banking :) It is possible to generate session ID on fly.... Include referer.... Include time.... But man-in-the-middle-attack can change referer to right one (let's assume all browser supports referer). So, it will just make hacker live a bit harder, but doesn't bring final solution.... >2.Breaking security of bank server. Which leaves the calculator system out >of the loop anyway. True. On server side, we uses several IP addresses and strong firewall/forwarder (all based on BSD systems). Many usual things (such as all in /bin/* and /sbin/*) are trojans, which doesn't do 'nothing' -> just inform us, that someone is doing something nasty. HTTP server Apache (a bit improved) runs in chroot, as non-root user, ALL other ports (both ways) are filtered by firewall. So, I hope we make hacker's live harder. Later in future, I want to divide system into more machines. Machine holding datas will be physically separate from machine, which communicates with client. Communication should be verry simple, but based on user secret key (sends to server crypted by another secret key, stored into external device). I belive, this will make direct server hack hard. If someone will want to hack server, he have few ways: 1. Hack Apache directly (and some way get shell - but he have to put his own, running standard will not help) - many attacks just execute /bin/sh :) [lame...] 2. Hack in some way our application server side (hmmmm :o} Trying to do everything for make it 'secure' - and hope audits will help too - find forgotten mistakes) 3. Hack firewall (nearly empty BSD instalation) - there is nothing except firewall/forwarder... Hack 'clean' kernel is pretty hard job - I not yet see remote exploit for BSD kernel. There were some DOS attacks (like reboot server) with IPF and similar, but no more 4. Stole somewhere calculator, get pin from user, authorize himself on firewall -> hack machine behind firewall - various users cab be authorized only for some services... Only few ppl can be authorized for usefull services.. But we end at 'people' factor... >3.Fysical access to and/or copying device. The device is protected by a four >digit code, I would assume it erases private key from memory after three >unsuccessful password-attempts. Getting the key out of the memory is hard >work anyway, and the encryption algorithm may be hard to reverse engineer if >it's not already known. True. Data in EEPROM of calculator is physically encypted by result of some hash algorithm, which input is initial pin. And autodestruction rulez. >Maybe I have overlooked something or misunderstood something in the system >as I have pretty much guessed how the system works. The system does seem >safe to me. It would be nice to see what others think of the banks system. >Have I overrated it? No, you understand exactly. Thanx for yours comments. I basically agree with all you write down. From possible troubles, you remind, I think one is 'real' one. And it is man-in-middle-attack in combination with stoling SSL connection. Or actually 2 troubles... The second is human factor... But it is question of 'application' itselfs to minimize its impact, because we can only *reduce* human factor. We can't (I can't imagine how) prevent it. I will welcome any comments/ideas - how to make system stronger... I looked around many many many other products/protocols/etc. but everything is far from 'secure' (and as I say, including my own bank's inet banking). In majority cases, form of man-in-the-middle-attack (well prepared) will get the job. Or small trojan. This is virtual word. Any idea ? Thanx, Best regards, Lada 'Ray' Lostak Unreal64 Develop group http://www.unreal64.net
This archive was generated by hypermail 2b30 : Fri May 03 2002 - 19:30:04 PDT