- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Admin
You can't protect form [sic] malice! Bwahahah!
Admin
Um, yeah. That's what locks do. They secure doors.
Admin
Fully Qualified Domain?
Admin
It's a bad analogy, but he's basically right. If the attacker has command line access to the system sufficient to control the database, you're probably screwed.
Encryption helps in the following circumstances:
It will not help if an attacker has control over your system. At that point they have access to whatever methods you're using to encrypt/decrypt your data, and you're basically screwed.
A better analogy would be trying to lock a prisoner in a cell that can only be opened/closed from the inside.
Admin
9/25 = .36
If he's not careful, he might accidentally stay an extra month.
Admin
Reminds me of a recent issue I had with a vendor's web component. The component has an XSS bug, and I showed the vendor how with a little javascript tacked onto the end of a URL when the page returned the URL was included in the vendor's javascript, and thus the javascript in the URL would run. This way a hacker could get access to cookies or whatever..... The vendor's response was basically "well, you shouldn't put that javascript in the URL there"
Yeah, I'll be sure to let our site's hackers know that....
CAPTCHA: nisl (Soccer fans?)
Admin
Best guess on FQD: Fully Qualified Designation? The full name of the organization to boot him if said hacker did manage to get in, perhaps.
Admin
Admin
Perhaps he's a Java Coder....
Admin
Admin
Uh-oh....the GGA again.....
Admin
[What security vulnerability?]
Admin
My apologies if somebody's already said it. I didn't read all the comments before responding, thereby breaking my own rule.
Admin
Perhaps their computers at the time had no usb ports. I doubt a usb stick is much use for transferring data when there's nowhere to stick it. (hmm maybe I should rephrase that)
Admin
Admin
What company was this? This sounds like excellent whistle-blower material. Presumably since they're working with three-letter agencies, they're dealing with information about you and me and everyone you know. IMO, they should be outed.
Admin
also, for those asking what FQD means - FQDN means fully qualified domain name, so it's not that most likely, and based on the tone of the article, the acronym was made up on the spot to poke fun at the governmental way of doing things. I swear, some people wouldn't know deadpan humor, or for that matter even sarcasm and satire if they were hit in the face with it :D
Admin
Thanks - it hits me now ;)
I was convinced there was a deeper meaning in this acronym so I went on search to understand what I'm laughing on, but it seems that wasn't necessary ;)
Admin
Oddly enough (or maybe not), one of the news headlines today is this: Data Breaches Booming.
Admin
Please, please tell me that this company has been charged and convicted of criminal negligence and has closed its doors.
Admin
Also the impression I get from "they'd just have to" is that they wouldn't even need to get root to access the database. If that doesn't strike you as a WTF then please never work at the same company as me.
Admin
Let me try to detail why database encryption is important. First, though, we need to define what it is. You do not place the DB on an encrypted volume, and you do not encrypt the DB files themselves. You encrypt specific fields in DB, say Social Security or Credit Card numbers. If, for some reason, you need to index on these values, then it becomes significantly more complicated, but that's largely irrelevant to this discussion.
The short of it is that yes, you do incur a performance hit, but the DB server itself doesn't need to be responsible for the en/decryption - this can be done elsewhere, such that, if it makes sense for the data, different fields can be encrypted with different keys. That's probably not likely in this scenario, but the important part is that the decryption keys can be stored anywhere - including in encrypted form that the system admin does not have the password to. So yes, you can encrypt the database and foil a user that has gained root access.
So there is one reason - you CAN foil a hacker that has gained root privileges. Another is for the same reason that you encrypt off-site backups. In a SAN or RAID system, you lose drives all the time. In most cases, the bad drives are shipped off-site to a third party company that has provided you with your replacement disk under contract. Though the entire database is not represented on a single drive from a RAID array, complete records most likely will exist. Should a malicious user intercept that disk, or should it be refurbished and placed back into distribution, your data is placed at unnecessary risk. For most businesses, this risk is vanishingly small, but for government agencies and financial institutions the risk can be unacceptable. To be sure, many agencies will destroy the disk rather than ship it off-site, but it is likely cheaper to implement encryption than it is to absorb the cost of failed disks in a data center.
Additionally, it protects against physical theft, which bypasses the need for root access. The government may place systems housing secure data at remote locations - embassies or military bases - that do not enjoy either the level of physical security or reduced threat of physical theft domestic systems do. It is unlikely that the most sensitive data would be placed at these locations, but there would likely be a need for some sensitive data to be available.
Lastly, if the database is encrypted, it helps protect against SQL injection type attacks. If someone manages to (via an exploited cookie as mentioned in the article, for example) inject a "SELECT * FROM TableName" query, they get only a minimal amount of usable data. The most important bits come back garbled.
Now, all of this assumes that the application is designed correctly. If they do simply encrypt all of the fields with the same password, and the password is stored in an init script (as opposed to a valid user login) or worse, unencrypted in the database itself, then most of these benefits are lost. So I re-iterate: if done correctly, encrypting the database provides significant security benefits.
And you are correct - defending against the sysadmin is probably silly - even if the keys to the database are protected from him, as you show there are other ways of obtaining them if you have the access and trust typically placed in the sysadmin, but the primary goal of database encryption does not include protection from the sysadmin, though making him work for access - thus preventing "casual" browsing of it - is a handy side benefit.
Admin
It doesn't take long for the soliloquies to start.....
Admin
Admin
That ".36" nonsense managed to turn a neat little WTF into nothing but an incredibly lame joke with an excruciatingly long setup.
Admin
The obvious solution is to just sell this information to competitors/foreign countries/whatever when he leaves.
Admin
If I worked there I'd be a little stressed about the lack of rigour from my colleagues. But seeing as though I nor any one of us work there, I fail to see why anyone gives a wtf about it. Why get so angry when it has absolutely no effect on your life whatsoever?
Admin
Right... after a project lead suggested to use a third-party script, deployed on a third-party server, in our internal financial web page, I kind of suggested not to, and spent 3 days adopting it (it's opensource); for which I was rewarded by "performance improvement plan" ("what could have been done in 30 minutes, took him 3 days"); ok, I talked to our network security people... I really thought they were interested in preventing this kind of solutions... they were not.
Admin
What to some is a funny joke, to others makes a whooshing sound.
Admin
Try 127.0.0.1
Admin
Ironically, I predicted one childish anglophone would knee-jerk ad hominems at that comment. Though if you aren't a native anglophone my prediction is only 75% correct.
Admin
Hmmm.
"Between the banks, brokerages, credit card companies, military, government and companies like this, it's amazing that we all haven't been identity-thefted into oblivion."
Hah!
I got around that by having so much debt that anybody who stole my identity would -pay me- to take it back!
Admin
What would Kirk do?
Admin
Hey, hey! Don't forget insurance companies.
Actually, my group in my ins comp employer IS encrypting fields as noted...
Only problems:
-Server without https capability uses security-through-obscurity instead to protect confidential data (no interest in my idea of replacing fixed-key replacement algorithm with something key based like... AES)
-most systems still have no encryption
-Some of the encrypted fields' only values are 'Y' or 'N' (suggestion of using salt was dismissed)
-Only 1 cobol module can see the key but all programs (& by extent programmers) can call that module.
-No procedure exists to change keys if the "hidden" one is compromised. (Changing keys would make all existing encrypted data inaccessible)
Clearly, the greatest risk is from programmers. Luckily, there is absolutely no chance of any programmer ever exploiting one of these bugs... despite the WTF-driven programmer turnover rate.
Admin
I call BS:
A security company smart enough to use PostgreSQL but too dumb to care about security even in the slightest. Fishy.
WTF does encryption have to do with it? Rather it looks to me like someone used the default PostgreSQL authentication scheme, which allows local (from the unix shell) logins without password. I guess I can see that happening, even though the fix is one line in pg_hba.conf, but...
Exactly WHAT is J. Random Web User doing in the Unix shell anyway? Until we get to the bottom of this, that is TRWTF.
Admin
Admin
This is thedailywtf.com. If there were layoffs, it'd be Jim.
Admin
Of course, that just means that there must be another part (perhaps the business logic engine) where the admins can get the info if they want. But the name of the game is really about reducing the exposure surface. (Of course, the sane approach involves vetting the admins and then not treating them like felons, but we know that many firms don't hold with this whole sanity business...)
Admin
Irrelevant - you don't need a Unix shell to do damage at root level, you just need some means of accessing data. In any case, the word "cookie" doesn't necessarily prove it's a web application.
Admin
No, really - Month/Day/Year IS A WTF. Somehow I find Day/Month/Year to be better structured way of representing the date. Anyway, I realize that people who use Month/Day/Year are the same people who measure their height with "FEET".
Admin
Sadly HR kept the end date stored in a similar format, and stopped paying him on April 11th
Admin
Admin
I cannot agree. I mean, working in a bank, it would be a complete nonsense (and many techies would be sipping martinis in tropical islands instead of working) if sysadmins would have full ability to alter account information.
Sysadmin job needs ability to run, maintain and configure the system, but for a secure sysem it should never mean ability to gain full access to the secure data stored on these systems, to get encryption keys of other users, to change anything without that change being logged securely; to do major alterations without four eye principle, etc.
One random example of such measures - there are simple commercial offerings for high security systems to store sensitive data (say, encryption keys for debitcard PIN checking) where full root access (not needed for any regular tasks, but system setup or reconfiguration) works only together with two physical keycards that need to be inserted in the system - and which are not available to the sysadmins, but requires presence of two different trusted officers.
If the idea of securing the company against any employee fraud seems nonsense, well, then your security is not serious. 99% of companies don't need serious security, of course, but here the whole point was that the customer presumably did actually need serious security.
Admin
94 comments and nobody's picked out the zinger.
Mike was so nice to get Jim a beanbag, but he put it on his desk, when Jim likes to bang his head against the cubicle wall.
He's worked for gov't too long - good idea, bad implementation.
Admin
Admin
(Sorry I can't remember the start of the joke. Probably something to do with a rod being the same as a perch. I believe the Americans have a similar joke using poles <get garment="coat" />.)
Admin
I do this too. Pisses my wife off; she prefers the American way because "that's how everyone does it". (We are in the United States, btw.)
Maybe we need to start an "Americans for Sane Date Formats" advocacy group...
Admin
You only like Day/Mo/Year because you're used to it. Since it is backwards from the universal standard of most significant digits first, it is equally inferior to year/month/day as any other date format.
BTW I see the flaming retards are still posting captchas in their comments. Next time call up your mom and tell her what your captcha was instead of wasting forum space with your inane irrelevancy.
Admin
Yeah, um, I embarrasingly didn't know how get that character or I would have. Now I can copy "∩" from you post. Do you have the symbol for union too?
That's what I get for using DOS, yea that's it, I'm using DOS, I can't be lame if i blame someone else :)