Slashdot Mirror
The Unspoken Taboo - The Never Expiring Password
anon writes "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."
I am not a cracker or hacker. But I know a guy who uses password trading websites for porn. According to him, once you get a password for one porn website, that same password will work for others. According to him, these porn members use the same password for all sites they subscribe to.
Once companies start losing money to crackers/hackers, then they will start issuing more complex security.
I used to work for a free adult hosting site. We stored the passwords in plain text in a database. One day, just for the hell of it, I pulled out the top ten passwords. They accounted for something like 40-45% of the passwords for more than 250,000 accounts.
If the new way is so good, how come the world wasn't going to hell before? Did Enron and Worldcom go bust because the passwords wern't changed? Or did they go bust because our government coddles corporate criminals - in the cases suits stealing money is even illegal in the first place.
I can understand mandating a security protocol for systems that protect information subject to privacy. But if I have a company, and the only thing on my computers is my company's design information, my company should be able to choose the appropriate level of security for our business.
Why is a password that a user has committed to memory that never changes worse than a password that changes every three months that a user has to write down?
paintball
I remember first using Apple Network Assistant to administer a network of Macs. The default password was 'XYZZY' which is, of course, the 'password' for Zork. Fortunately, even back when said network was a mix of OS 7.6.1 and 8.1 Macs, the Zork reference was too far in the past for the middle school students to even have a clue about....
End of Line
Any Web site offering you an account of some kind requires authentication, invariably in the form of username and password. Many users will just reuse the same username and password. Those that don't must use a password manager, whether it's the Web browser's autofill or a real, live, dead-tree notepad.
Most of these sites require you to transmit your password in the clear. So not only does the Web site operator have your password (which could be used to compromise your account on other sites if it's the same), but so does anybody sniffing your network.
Both of these problems would disappear if we used public keys to authenticate. You generate a key pair, and supply the same public key everywhere when creating an account. Your browser acts as the key agent (or connects to one like ssh-agent) and uses the private key to respond to an authentication challenge. No password is sent to the server, ever.
HTTP Digest authentication also neither transmits nor stores cleartext passwords, but the Web site operator does have to have it to set the password in the first place. HTTP authentication in general currently suffers from the problem that there's no specified way to log out. A solution to this problem was proposed through the W3C about six years ago, but it hasn't been implemented that I'm aware of.
In general, it is safe and legal to kill your children. -- POSIX Programmer's Guide
> The locksmith just changed my locks! Did he keep a copy? Is he trustworthy? I don't know... Shit!
:)
:)
I always like this.. A good locksmith would know how to pick the lock. A smart locksmith would have noticed that you leave your downstairs window unlocked.
My father used to tell me, locks are for honest people. I agree.
Several times, in nicer office buildings, I've found myself locked out of offices where I should be allowed. They use a special 'security' key, which is one or two tumblers longer than a regular key. I've opened them in about 10 seconds with a car key and a credit card. Sometimes I've found it easier to just pop the drop ceiling out, and climb over the wall too, assuming there is no firewall between point A and point B. Usually inside offices don't have them.
But, when it comes down to it, if I wanted to get into your house badly enough, I'd just kick in the door. I have yet to find anyone who uses a New York deadbolt other than me.
I went to a "secure" facility a few weeks ago. I was inside a 'mantrap', waiting to be allowed through. I started laughing at the guard, after he took too long to let me through. The guard didn't understand why. Their "security" guard was behind 2 inch thick security glass. The frame around it was steel. The door had steel bars on it, and a pry guard. He pointed all of this out to me, and I laughed again.
Someone had swung the door open too far a few times, and knocked a grapefruit size hole in the drywall. I knocked on the wall right under the bullet proof window. It was just more drywall. I then asked "What would happen if I shot through here? What would happen if I knocked a hole in the wall, and put 12v to the door latch solinoid? I would be in, and no one would find you until shift change."
Ok, it could have been other voltages, I was just screwing with him.
Ya.. There aren't too many places that are really 'secure'. It's simply a matter of how much risk a person is willing to accept in the entry to said facility. In the above case, it was easier to ask "will you please open the door now?" He stopped giving me grief every time I came through. He already knew I was authorized.
Serious? Seriousness is well above my pay grade.
I've notice many people here are misunderstanding the article. While the article does incorrectly state that 'all applications have hard coded passwords', I think what he meant was that 'nearly all applications that access secure resources over a network have hard coded passwords', and this is quite likely true.
For example, Apache has no hard coded passwords. But... what if you have your web application accessing a MySQL database on a different server? Well, then you need to login to that MySQL database. The password is stored in your web app. When was the last time that password was updated? And that, in theory, is easy to do because the web app isn't compiled and it's stored in a single location.
Another common scenario is a compiled Intranet app to, say, access Inventory information from a central database. It's common to have hardcoded logins to the database or web servers in apps like this. In fact, almost any app that does not require a user login, but does access secure resources, probably has a hardcoded login stored inside somewhere. Legions of these apps were coded by programmers who may be very competant, but are not security aware... they could well be stored plaintext right in the binary.
So the article may have been overgeneralizing, but it was quite accurate when it comes to business software.
The Raven
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
Mine's a completely random 12-character string. My passwords for every other website (and other password-protected things) I use are also (different) random 12-character strings. They're all stored in my password storage app (gpass), which is protected by one extremely strong password I spent five minutes memorising (and will change next month). This whole thing only took about two hours to set up, and it's certainly worth it in terms of peace of mind.