Re: Security - ciphers - autentification
From: Lada 'Ray' Lostak (ray@unreal64.net)Date: 05/02/02
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Lada 'Ray' Lostak" <ray@unreal64.net> To: "Martin" <martin_o@algonet.se> Date: Thu, 2 May 2002 09:34:52 +0200
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
