Hackers have stolen the login credentials for more than 8,300 customers of small New York bank after breaching its security and accessing a server that hosted its online banking system. The intrusion at Suffolk County National Bank happened over a six-day period that started on November 18, according to a release (PDF) issued …
So then Dan,
it was a unix/linux system them, being as the only way to rebuild your server from base is in a Unix/lLinux enviroment.
Pray tell me, how does xss/cryptoapi/ etc etc etc etc unfixed MS bugs/flaws play into the scenario of seriousness, when now you're talking about 8k+ bank accounts being compromised.
At least, when an MS server is compromised you don't have to rebuild from scratch, or compensate x thousand/million/billion customers.
Kinda makes IE6/7/8 flaws look microscopic, maybe this will put it into perspective for you.As it should have done a long long time ago.
"""it was a unix/linux system them, being as the only way to rebuild your server from base is in a Unix/lLinux enviroment."""
You'll find that people use 'build' when they install just about any operating system on any computer. I know I've seen it applied to Windows servers plenty of times in plenty of different organizations.
"""Pray tell me, how does xss/cryptoapi/ etc etc etc etc unfixed MS bugs/flaws play into the scenario of seriousness, when now you're talking about 8k+ bank accounts being compromised."""
What? Unfixed bugs are unfixed bugs. Plus nobody said a bug was even at fault here, for all we know the compromise started with a botnetted Windows workstation.
"""At least, when an MS server is compromised you don't have to rebuild from scratch, or compensate x thousand/million/billion customers."""
If you have a compromised system and you don't rebuild from bare metal, you're really risking not removing all sorts of malware. Also, plenty of MS servers have been breeched over the years, often with far more than 8400 customer logins revealed to intruders. And the use of a non-MS environment doesn't cause you to compensate billions of customers.
Also, what have you been smoking?
Unix/Linux enviroment ?
> it was a unix/linux system them, being as the only way to rebuild your server from base is in a Unix/lLinux enviroment.
Like how, what was it running on upto Dec 24 ? What is it about other systems that prevents rebuilding from base. Install system, apply patches, apply customised configuration ..
> At least, when an MS server is compromised you don't have to rebuild from scratch, or compensate x thousand/million/billion customers.
You mean like the Heartland fiasco ?
Login credentials WTF?
What kind of numbnuts, completely unnecessarily stores login credentials on a server?
And a BANK at that!
A BANK was storing passwords in cleartext? Not only should they compensate customers for any losses, their systems engineers should be charged with criminal negligence.
Where do you store them then?
Surely you need to store them (in a suitably tightly encrypted form) somewhere? otherwise how do you validate them? Storing them on a usb stick might help, but it would be a bit of a pain expecting some poor sysadmin to pop the stick in every time someone wanted to log in.
I'm with AC
You store them as a well-salted hash. No?
You don't store them
You store a one-way hash of them or store the RSA public key when the user has the private, or any number of things, you do not store credentials. Ever.
@ Neal 5
Are you Steve Ballmer?
Safe as a bank
... to Claude Cockburn's (apocryphal) Times' headline-competition-winning entry:
"Small earthquake in Chile. Not many dead."
Us retailers have to be PCI compliant - I hope the standards council takes them to the cleaners.
They didn't notice a six day attack?
Stupid that they don't say how it was done and what the exploit was so we can learn. So we'll have to assume that they probably also did not learn from this.
This feeling is enhanced by the pdf: "the unauthorized access occurred during a finite, SIX-day-period" which tells the whole story about their security and the monitoring going on at that "bank"...
(Paris, since she knows to check the locks every day before going to bed)
I think it's rather sweet
...the way this little local bank, with branches the length and breadth of Suffolk County, (land area 900sq miles, somewhat less than the real Suffolk), calls itself the Suffolk County NATIONAL Bank. Is there an unknown secessionist movement there? The Suffolk County National Party? The Suffolk County Republican Army? It does seem a bit silly and grandiose - a bit like calling a local professional rounders competition the World Series. Or believing that your village bye-laws should automatically apply across the globe.
So don't be hard on them - would you expect tight security at the village Post Office? - of course not, old Mrs Scroggins behind the counter knows everyone by sight - she doesn't need all these new-fangled security systems and encrypted passwordy things! And I'm sure this cute little bank is just the same.
Cute little bank?
Yes, you're probably right.
[streetview, give it a few moments to load itself up]
That *was* a petrol station once upon a time, wasn't it?
No thanks... i like my passwords hashed... HASHED
This is quite usual for small banks.
I worked on one in the City a few years back to investigate why their 512k VPN link to their HK office was slow.
Not only did they attempt to leave me (an external contractor who had literally just walked through the door) in charge of their routers and firewalls with full priveledges, it turns out that the unusual traffic was a web-cam pointed out at the eye across the Thames and they were watching it in Hong Kong !
If want a secure bank, try Deutcshe Bank - they have > 100 strong firewall teams.
Big Banks versus small
Quite true that small banks tend to be rube. But I am not necessarily impressed with big banks sheerly due to numbers. The most positive thing about 100 firewall teams is the opportunity for internal schooling and cross-checking. But reality is that big banks use quite a bit of those IT resources even firewall teams internally and not on external customer websites. Then add in that with millions of customers Deutshe bank actually may have fewer security man hours per customer than a rube rural bank.
You just hope that the big bank degree of professionalism is that much greater and well applied. But it is not always. Usually 30-50 percent of the teams are interns and other trainees who when they start maybe no better trained than the least of the rube bank security people. So it often comes down to how well their mentors supervise them and when mentors get sick, etc. Thus stupid stuff can still happen especially if some well-trained mentor is ducking a tedious but essential monitoring or configuration task and foisting the job on some marginally qualified trainee without frequent checkups.
@AC 13th January 2010 11:07 GMT
Go get in the healthcare queue to get your anti-psychotic prescription refilled.
"National" in the name of a US bank has nothing to do with size and everything with how it is chartered. It is a relic from when individual states still chartered banks.
Banks can still be State or Federally chartered. And that is all that the inclusion of State or Federal means --- which set of regulations takes precedences (well usually both apply to a certain extent but...).
Good point. The article does not say how the server was compromised.
However if true passwords in the clear DOES point to a default *NIX install or a custom web database. While not great MS product do default to some level of encryption. Only a few *NIX distributions and *NIX databases even have the ancient options to store passwords in the clear...let alone the default that let the unsophisticated fall into that trap.
I would go for foreign logging installed to a Windows IIS website as probably more likely. Or even simple eavesdropping on a logon page that defaulted to HTTP as Hotmail.com does. (what is the point of a password Hotmail.com?) Of course in the latter case I would suspect a new visiting security auditor simply counting the number of unique logons rather than the idiot who installed the logon page with HTTP instead of a working HTTPS page.
Oops! Clear text in Access
I should make it clear that I consider using Access to do website logon as a "Custom Web database". It certainly is not one of the easy default method of storing website logon for MS products.
But yeah Access could store password in the clear as could MS-SQL if the fields are simply data fields rather than regular SQL password structures. Doing so would save licensing costs. Not much cost if the small bank website was done right (exactly how many people do you expect logged on simultaneously) but lots versus stupid brute force (SQL and windows server license for each account).
But then you can pervert any product, MS or *NIX, to build stupidity and scam it to some tiny local bank as high quality programming...if they have no one really computer literate in even the surface aspects of actual professional server and programming practices.
Passwords stored where?
It is nice if the website can get nuked and the user passwords are still good when the website comes back up.
So even with a custom website logon database...why store it on the web server?
Encrypted or not, its an unnecessary exposure. The website itself is your biggest attack surface. It will go down some day. It is nice when loss of the website, minor or not, does not stop other business processes. It is good when you do not have to tell all your customers to come in to the bank to revalidate and enter new passwords.
So really the issue should have been a website application that was written to avoid SQL injection in the logon phase when querying the logon database stored on another server -- at least for this particular problem. Of course that might be another virtual server but from a critical data and critical processes protection standpoint - website should be "disposable" in the short term.