Every security savvy professional lives with the daily fear of the “never expiring password” being exposed. It’s the unspoken taboo, the wide open back door in every corporate network. But no-one ever acknowledges it or discusses it. All applications have got pre-defined passwords that never change. Which means developers, privileged users and hosting third party service providers will all have access to these passwords.
The Unspoken Taboo – The Never Expiring Password
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Currently, the ultimate password of that type is the signing key used to sign X-Box CD’s.
If that ever leaks out, MS will have a very bad day.
“If that ever leaks out, MS will have a very bad day.”
Somewhat likely no single person has it. More than likely several people have portions of it.
Edited 2005-12-07 23:53
Kinda like trying to get the Enterprise to self destruct? nm…
Any leak of a private key for digital signature or certificates would be disastrous. Imagine what would happen if their key for signing certified programs would leak out.
Still, it’s not exactly like a password… Few people would share their digital key, yet they have no problem with telling their password to somebody they believe as trustworthy. At work, I have root access to many servers, technically having access to grades even if I am a student myself. And they don’t change passwords that often…
Security is often set aside for convenience.
Reminds me of these unfortunate BIOS “master” passwords. I’m not sure if these are still common practice, but the bad thing is that an evil BIOS and/or mainboard manufacturer could hide the fact. Or does anyone disassemble the BIOS? 😉
Or does anyone disassemble the BIOS? 😉
No, we just clear CMOS or flash another BIOS version.
Browser: BlackBerry7730/4.0.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
Security is a nightmare, a disaster, with more important problems than the non-expiring passwords.
Just try to tell the network guys to change their passwords often… They will hang you.
The philosophy of red and black networks is usually taken with corporate information security. Black networks are insecure and red networks are secure. Everything on the black network needs to be encrypted and secured, but once you get to the red network, it can be in the clear. From my work with the NRL (Naval Research Labs) apparently this is quite standard practice on highly sensitive government networks. The philosophy is quite sound but it often doesn’t transfer well to commercial networks. The reason being is that what the corporate networks view as their “red” networks don’t usually have the same level of security at their borders as do the government “red”.
So these hardcoded passwords really are an issue. I spent 2 inernships at Intel actually modifying much of their internal business software to use account information from configuration files instead of being hardcoded. So at least IT is starting to wisen up a bit.
I still think though that it doesn’t do much good if the passwords are sent in the clear as they often are for DB connections between applications. Nobody in their right mind these days would use telnet on their UNIX servers instead of SSH, even on a red network, there just no need to. But people have no problem using unsecured database connections. This is the main problem that needs to be taken care of. I haven’t checked so maybe the new RDBMSs out there are taking care of this. I hope so anyways.
P.S. The edit was simply to fix some typos.
Edited 2005-12-08 01:23
At IBM I had my pick of various development machines to log into, but only one of them seemed to accept my SSH connection, so that became my primary dev machine.
Later I was talking to the machine’s sysadmin, and when I mentioned I connect to the machine using SSH, he said that everyone else uses telnet, and that most of the devlopment machines don’t even accept SSH connections.
So apparently it isn’t so obvious that people should use SSH instead of telnet, even in a highly technical workplace.
You hit the nail on the head these vulnerabilities exist mainly where developers or DBA’s are given management roles or think they can architect computing environments. Leave architecting and building environments to the SA’s people. Any Systems Administrator worth his salt would find these type of problems and nail the programmers and or DBA’s butts to the wall.
You’d be suprised how many places don’t know what ssh is. Where I work (for now, layoff next year) we use telnet for everything on the mostly private WAN because Windows only comes with a telnet client and they don’t understand SSH.
You’ll find this in a lot of older IT shops.
Security will not be a priority until it’s required via legislation or liability. Back in the 80s I worked in hospital IT and I saw some unbelievable handling of patient data. We would drop patient reports with sensitive patient data in front of door in public hallways. Passwords were taped to terminals (it was the mainframe era) everywhere. These were common practices and IT had no power so the government stepped in with HIPPA.
I expect the same sort of legislation in regards to credit card and customer info sometime soon.
Edited 2005-12-08 14:57
Heh!
The last time I used telnet was 9 years ago in my undergrad CD classes to telnet in and drop off my homework. An that was only for one or two semesters. After that it was SSH – no SSH – no login – NO GRADE!
Actually, the program I’m on uses rlogin and rsh exclusively (its associated with NRL as well). Of course it has very strong level of security at its connection to the “black” network… there is no connection, its a completely isolated network.
I have no doubt that the problem of “never changing passwords” is a genuine concern, but I have difficulty believing that there are really that many applications with *hard coded* passwords. Can it really be the case that “It is virtually certain that there is not a single business critical application in your company that isn’t wide open”?
It’s also not clear to me how digital vaulting can eliminate the problem, without all of those badly written applications having to be re-implemeneted at the very least.
Sorry for being so very cynical! But the article would be more convincing if it hadn’t been written by the European Director of Cyber-Ark ( http://www.net-security.org/article.php?id=844 ), who are the “networking company behind vaulting technology” ( http://www.cyber-ark.com/cyber-ark/index.asp ) .
Edited 2005-12-08 02:20
I agree entirely. Writing alarmist articles along the lines of “your entire network is going to collapse tomorrow because of this virus / worm / other threat that only WE can protect you from!” then trying to get them published on independent-looking sites appears to be the official pastime of the security industry.
I don’t agree that it would be more convincing if it wasn’t written by someone who actually deals with these kind of problems.
If you need advice on biometric solutions, are you going to ask for information someone who actually works with biometric products and knows the good and the bad points or a security consultant/blogger that just happens to write something on the subject?
That’s not a fair comparison. This article doesn’t purport to be written about digital vaults for the benefit of someone who’s already decided they want a digital vault. It purports to be about a general security threat. It’s like a biometric security salesperson writing an article about keeping your wine cellar safe but with the ultimate goal of selling you biometric security. It’s not the same as a biometric security salesperson writing an article that is avowedly about biometric security.
And besides, even if they _know_ the bad points, do you really think a salesperson is going to _tell_ you about them? Only if they know you’ll find out some other way anyway. Otherwise, not a chance. Do you see the drawbacks of digital vaults mentioned in this ‘article’?
Edited 2005-12-08 09:19
“It is virtually certain that there is not a single business critical application in your company that isn’t wide open”
Unsubstantiated fear mongering.
“So where is this wide open back door? In every one of your applications.”
More unsubstantiated fearmongering.
“and since the credentials to logon are in the application, they are embedded in the code.”
Ever heard of this amazing new concept called “configuration file”? It actually separates configuration data from the code and it’s been all the rage for, uh, some 20 years or so.
“Your applications are accessing valuable business critical data thousands of times a day, using the same user ID and password.”
It doesnt really matter if it happens one time, thousand times or a million times per day.
“The good news is that there are solutions available that will allow you to once and for all face up to this unspoken taboo and eliminate this threat.
The solution is digital vaulting technology.”
Oh yeah, that’s a surprise conclusion. What a coincidence that Cyber-Ark makes “Digital Vaults”…
I cant help but wonder why OSnews keeps linking to thinly veiled product advertisements like this.
My favorite at work.
nortel:nortel
root:m0nday
Where do you work?
wadda joe meen pawwuts?
i prefer
root:beer
or just autologin instead of the daily changing to some
combination of at least 256 random characters.
utf8 passwords would be fun though.
Even more dangerous are the servers everybody have forgotten about but are still on-line.
Ever configured a new server, typed the password, sent the server, went to do some maintenance and not be able to type the password?
Only because you typed the password on a FRENCH keyboard and you now have a SWISS/FRENCH keyboard instead???
Time for a “passport” type login that logs you into all things on your corporate network (yes this exists, we got a demo of it last week!).
Put in smartcard and biometric readers on your terminals and there it is – no more need for passwords as we know them 🙂
I know that never expiring passwords is a problem for the admins and the security freaks among their ranks, but their paranoia is making things worse. Here is an example:
You need a password at least 10 characters long
You need to have at least one special char (#@!$%^& etc)
You need to have some numbers thrown in
The case must be mixed.
ok, so can someone tell me how I can remember this kind of password (or many of these kinds of passwords) vv!th0ut r3z0rt!ng 2 yooz!n l33t sp33k ?????
Overall, I’m with you. Except..
“Put in smartcard and biometric readers on your terminals and there it is – no more need for passwords as we know them 🙂 ”
Do you trust your company that much? I was going to stop travelling to the US when I heard they wanted to fingerprint canadians. They backed off on it. You never, ever, ever want to give someone, especially corporate or the government types something that uniquely identifies you.
All data, once it exists, can very easily get moved somewhere else.
Or maybe I’m a paranoid freak
– Microsoft Fanboy
Well OK – I am not so hot on the topic of biometric security – but a good option would be for every terminal to have both a smartcard reader and an RFI reader, and only a limited amount of computers that that particular card can access.
So I come into my office, I have the responsibility over 10 PCs (arbitrary number) – I put my card in – the smart card reader reads it, the RFID reader reads it, they do their little dance, they both consumate the marriage – they determine what sort of permissions I am allowed – and in a few seconds I can use those 10 computers and I can log into any services that I am allowed access to – no passwords to remember – no l33tsp34k – no problems
I need access to systems on a daily basis that run a wide variety of operating systems and that require passwords with varying requirements, often with incompatible requirements (the Unisys mainframe does not accept password longer than six characters, while some intranet sites require eight characters as a minimum).
I also use multiple signins on some servers, since I have my own developer user account and each application that I support has its own user account under which it runs.
A passport could simplify things, perhaps, but I think we’re a long ways yet before it could address all of the passwords that some of us required.
Use a bloody password application.
I have a different password for everything I use that’s protected with a password. That’s hundreds of passwords. They’re all completely random 12 character strings. They are all stored in gpass, a password management program. It has one master password, which I make a very strong password but based on a scheme which makes it easier for me to remember, and change every month. (I base it off a “real” word or set of words, but not a dictionary one – one from fiction – in another language, and do some character substitution, making sure never to make it less than 10 characters long, and changed every month or so). It’s really not very difficult, and vastly improves your personal security. And you can even put the password database on a USB key and carry it around.
the jist is “developers have access to production data”
no shit? thats certainly a thought provoking idea. here’s how to fix it
1) pay developers well
2) do treat them like shit or abuse them
3) select only people that you trust and know for developers
4) keep a professional atmosphere with developers, and expect the same from them
I don’t agree with #2.
How is treating your developers like shit and abusing them supposed to help the situation?
You’re fired. There is no such thing as a password that never expires, just passwords some lazy admin never changes. Anyone caught hard coding one will be shot.
Password protections can be circumvented by three means: technical circumvention, intrusion, and attack.
Technical circumvention means coming up with a method that completely circumvents the password checking process. The password is not relevent, so expiry is also not relevent.
Intrusion is simply devising a scheme to snoop and grab the password. Be it key logger, capturing plain-text password moving across a network, whatever… Here, the current password is captured directly and is readily recaptured if changed. So, expiry is, again, not an issue.
Finally, there’s attack. Dictionary or mathematical, the idea is that you have access to a system and a protocol for testing random passwords or generating new ones with equivalent hashes according to the protocol used. In this secnario, it will take a predicatable amount of time to defeat the password, and the compromise lasts until changed. Here expiry might make sense as long as a password’s life time is that of the time to break it or less. Otherwise, expiry is equally useless. Doubly so if the frequency of expiry is high enough users feel compelled to select easier passwords.
you forgot the simplest method of all
you ask the person that has the password: “how many fingers do i need to cut off before you give me the password?”
preferably with there finger already in a garden sheer
you forgot the simplest method of all
you ask the person that has the password: “how many fingers do i need to cut off before you give me the password?”
preferably with there finger already in a garden sheer
Or in the case of biometric security : “Which finger is it you use for the fingerprint check ? Wouldn’t want to cut off the wrong one now.”
As seen in : http://www.schneier.com/blog/archives/2005/04/security_risks_2.html
Although the sales angle might not be enough to discredit what this guy says, I would be very hesitant to believe this guy’s claims about security problems based solely on the fact that he can’t figure out how to change the password on his well-documented security system. Either he isn’t smart enough to figure out what is written in a good manual, or else the manual is poor and he doesn’t care enough to contact technical support for instructions. Either way, he doesn’t sound like a good source for security solutions.
http://www.avatier.com/
These are the guys that did a demo for us a couple of weeks ago.
Maybe not perfect, but it is a start
there are standard keys for construction equipment too. for example, every bobcat skid-steer loader takes the same key.