1996-05-05 - Re: Bank transactions on Internet

Header Data

From: “E. ALLEN SMITH” <EALLENSMITH@ocelot.Rutgers.EDU>
To: watt@sware.com
Message Hash: 67974c52ed339b81f0e1e3b19f2cfcccd1f9134e4a4b5156c0dc835b2ed2847f
Message ID: <01I4BKYQ0HBO8Y53GG@mbcl.rutgers.edu>
Reply To: N/A
UTC Datetime: 1996-05-05 05:32:27 UTC
Raw Date: Sun, 5 May 1996 13:32:27 +0800

Raw message

From: "E. ALLEN SMITH" <EALLENSMITH@ocelot.Rutgers.EDU>
Date: Sun, 5 May 1996 13:32:27 +0800
To: watt@sware.com
Subject: Re: Bank transactions on Internet
Message-ID: <01I4BKYQ0HBO8Y53GG@mbcl.rutgers.edu>
MIME-Version: 1.0
Content-Type: text/plain


From:	IN%"watt@sware.com"  "Charles Watt" 16-APR-1996 13:06:06.52

>First, the U.S. banking system is very nice to account holders.  The banks,
>rather than the customers, assume all risk associated with security problems
>in telephone banking, ATMs, etc...  Internet banking is no different, which
>explains why so few banks have jumped onto the net with real transactions.
>If an SFNB customer should lose any funds due to a security problem, SFNB
>pays, not the customer.

	That would depend on whether the customer can prove a security problem,
because otherwise you're going to get a lot of con artists making a lot of
money off of you.

>Second, in order to break the SSL-protected password of an SFNB account
>holder, you need access to the encrypted data.  This is not easy to obtain
>over the Internet, and would generally require illegal activity in order 
>to gain control of a host within the Internet infrastructure or collusion 
>with the account holder.  Should an attacker crack the key and obtain 
>the account number and password of an SFNB account holder, they are clearly 
>warned upon login that they are engaging in illegal activity.  Once they 

	One, ever heard of a packet sniffer? If the account holder is on an
Intranet, then someone within it could easily get such information. Two,
somehow I suspect that the penalties for computer breakins are significantly
less than those for bank fraud/grand theft; they aren't going to matter if
you're willing to take the risk.

>have logged in, there is no way to transfer money out of the account 
>without leaving a target address and phone number for the recipient.  
>Furthermore, any payment to an individual or unknown entity would be 
>made in the form of a physical check that would have to be cashed at
>a physical bank.  The whole process is heavily audited with real-time 
>audit filtering and pattern matching capabilities -- SFNB is, afterall, 
>running on a military grade secure operating system (see SWP at 
>www.secureware.com).  Any security system that is deployed should be
>compared against the value you are trying to protect.  It seems like a 
>pretty big risk to an attacker -- and I assure you SFNB will prosecute.

	Target address and phone number? Make fake ID, get yourself a PO box
and a telephone forwarding/answering service (giving the PO box as the
address), then target it there. Use the fake ID at a check-cashing place. You
can make the fake ID in whatever name you want, which makes it easier.

>Finally, I whole-heartedly agree that 40-bit encryption is far too weak 
>for many applications, and that the current export limitations are absurd.  

	I'm glad you realize that. I've edited out what look to be
improvements, which I hope for your stockholders' sake you've implemented.
	-Allen





Thread