Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

KM (4)

  (email not shown publicly)
AOL IM: perlguy13 (Add Buddy, Send Message)

I wrote a book, maybe you will buy it. Writing CGI Applications with Perl []

Journal of KM (4)

Thursday November 13, 2003
01:56 PM

Online Banking

[ #15750 ]

My local bank is very local. Only a few branches. They have, like many banks, online banking. For some reason, I trust large banks, and credit card companies, with their online banking apps. Maybe I assume they have a team of people who work on it, and it goes through rigid Q&A and security auditing.

Anyways, my local bank uses a system I think was created by a local internet/hosting company.. at least it is hosted with them. It's also apparantly written in Perl, and running on Linux. The company I *think* wrote the system basically seems to do Windows based hosting, and says they do Cold Fusion and ASP programming. Not Perl, or Linux/BSD development.

On further inspection, I see this comment (and a few more) in the HTML:

<!-- RM/COBOL Runtime - Version 7.10.00 for Linux (Intel). -->

And this at the bottom:

<!-- COBOL STOP RUN at line 1692 in /U/PGMS/OBJ/ACCTLIST (/u/pgms/obj/acctlist).OSMCSINITIALIZE called! -->
<!-- OSMCS called! -->
<!-- Mcs Function = 8; McsPtrArea = 0x0 -->

So, it's COBOL.. at least in part.

I'm not sure why, but this makes me nervous. Has anyone ever contacted their bank to ask what sort of security audits, checking, Q&A, etc... which their online banking apps have gone through? They use 2 cookies, one with a session ID, and one called 'pass', which seems like a encrytped version of the password. When you log out, they clear the 'SID' cookie, but not the 'pass' cookie. And, neither of the cookies are secure, although the site uses SSL.

So, I took the contents of the cookie, which looks something like (this was NOT it, obviously):


And I thought to myself, "Hey, this just look like something passed through crypt().. not even a hash."

So, I did this:

perl -wle'print crypt("MY PASSWORD", "AB")';

Lo-and-behold, it prints out what is in the cookie. So, it's storing my password crypt()-ed in a non-secure cookie, and doesn't blank it out on logout.

Am I being *too* paranoid about this? I'm pretty sure the userid naming convention is a standard one. We didn't choose it, and it isn't random. So, if you can view someones cookie, you know the salt to use with crypt and could brute force the password without trying to actually log on (which would lock the account after 3 tries... according to an error message I viewed).

If I have a concern about the security for one thing in a system, I don't trust the rest of the system. Would I be out of line (I don't think I would) by asking the bank to provide information on security audits done on their online banking system? Took me 5 minutes to view a cookie and get my password from it... you'd think someone would have caught that.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Just because you're paranoid doesn't mean they're not out to get you.

    I'd be asking alot of questions, and I wouldn't stop asking until they answered every single question.

    Best case, they hire you to code the new and improved app. Worst case ... well, I can't think of one.

    Or, you could start sniffing and make a ton of money. ;)


    If things get any worse, I'll have to ask you to stop helping me.