SoylentNews is people
SoylentNews
Nick and Margaret: The Trouble with Our Trains is a BBC Two show featuring Nick Hewer and Margaret Mountford, who explore "the sorry state of the British rail network."
The dynamic duo's travels took them to the Wessex Integrated Control Centre, located above the platform entrances at London Waterloo railway station, manned 24 hours a day by teams of controllers from both South West Trains and Network Rail.
[The] documentary revealed more than it planned this week, exposing the passwords used at a rail control centre.
The article features a frame of the video which shows the complex login credentials taped to an LCD panel of a Windows XP terminal.
One might wonder if overstrict password policy brought this about, except obviously a strict password policy would not allow the password that is stickied to the monitor..
(Score: 2) by snick on Monday May 04 2015, @11:40PM
In other words the old system was trivially remotely vulnerable.
Not. True.
In order to "hack" an easily guessable password, either the system must allow multiple login attempts without throwing up a red flag, or the hashed passwords have to be stolen. Password nazis make the assumption that insane password policy (onus on the end user) are manageable and actually securing the hashed password (onus on ... well, usually on the password nazi him/herself) is an impossibility.
SECURE YOUR FUCKING SYSTEMS AND PASSWORDS THAT WE HAVE BEEN TOLD ARE WEAK ARE ACTUALLY JUST FINE.
(Score: 3, Interesting) by vux984 on Tuesday May 05 2015, @12:22AM
In order to "hack" an easily guessable password, either the system must allow multiple login attempts without throwing up a red flag
So it throws a "red flag". Then what? Anyone serious about remotely guessing passwords will throw them at you from various random ip blocks etc. I run an SFTP server at home for example, and its constantly hit with password attempts, after a few fails from an ip it throws up a short ban on that ip address, and I can review the logs. But what's the point, every day, there's dozens to hundreds of login attempts from somewhere or other.
So if its easily guessed or present on a top 5000 passwords list or something they'll be in within a few days. A few minutes if they have a botnet.
Password nazis make the assumption that insane password policy (onus on the end user) are manageable and actually securing the hashed password (onus on ... well, usually on the password nazi him/herself) is an impossibility.
Oh i fully agree with you. But end users have to live in the world as-it-is and need mechanisms to cope. Even if you convince your own internal IT admin of a sensible policy; so what... I'm not going to convince the other 50 websites and systems I need access to. From Google to Microsoft to my registrar to Amazon... to that place I buy used lego...
PASSWORDS THAT WE HAVE BEEN TOLD ARE WEAK ARE ACTUALLY JUST FINE.
Yes, at least some of them are. But an awful lot of them appear on a top 1000 password list. That's why its a "top" list.
Securing the password hashes and properly logging accesses/access attempts only gets you so far. If your users are using a password on a top list somewhere, they'll get in.
(Score: 2) by urza9814 on Tuesday May 05 2015, @07:08PM
I'm not familiar with any password lock-out systems that work the way you seem to be assuming. Every one I'm familiar with locks *the user account*, not the IP trying to connect. So it doesn't matter how large their botnet is, they still only get three tries. And then generally the account is locked pending manual intervention, which may be hours or days before they get another three attempts. Good luck brute-forcing your way past that...
Of course, a decent password is still better than a "most common" password, but if you're relying solely on password complexity to protect you from a brute-force attack, you're doing something wrong.
And regarding the local attacks -- Where I work, if you want access to a system, you submit a request and someone who has no idea who you are or what you do makes sure you included the required information and approves it. Usually you do have to get it approved by one of your ten managers, but they don't *really* know what you need either so they'll approve anything. And people share passwords, and there's some common service accounts...of course this is for our PT environments, but those do have production data. The actual prod environments are a bit more locked down, but anyone who works here could easily get read access at least. So it doesn't matter much if the password is stuck to the monitor, because anyone in the building can probably access that account anyway. And if the concern is that they might use that computer on someone else's account...that would all be captured by the security camera. It's bad practice, sure, but it's far from the top concern in the vast majority of cases. Except one like this, of course...
(Score: 2) by vux984 on Tuesday May 05 2015, @10:47PM
Every one I'm familiar with locks *the user account*
Those are the exception not the rule. Hell, these days even most corporate office systems don't have policies in place like that anymore. Far too easy to DOS an entire company. Think about it... does gmail or office 365 or facebook or twitter or amazon or your domain registrar or dropbox or even soylentnews... or any major site on the internet lock you out like that after some small number of attempts? Can you imagine just how much havoc you could create if they did?! I've even seen corporate guys DOS themselves out of their own systems under that regime ... where they have a laptop or tablet at home periodically checking their mail or something; and then they reset their password at work; and the laptop at home just hammers on the account with the old password locking it out within minutes of it being reset... all day long because there's nobody there to turn the damned thing off. And getting IT throw in a firewall rule just to block some guys home IP address until the end of the day is too much grief unless its a CxO.
So it doesn't matter how large their botnet is, they still only get three tries. And then generally the account is locked pending manual intervention, which may be hours or days before they get another three attempts.
Yes, If you prioritize keeping unauthroized people out above getting authorized people in that is exactly what you will achieve. That will work well unless you have users that NEED to actually login.
Of course, a decent password is still better than a "most common" password, but if you're relying solely on password complexity to protect you from a brute-force attack, you're doing something wrong.
What mechanism would you suggest for facebook et al beyond what I've suggested? Throttling the incoming brute force searches so that it will take them generations to search the password keyspace is about as good as it gets. Locking out millions of users who have no real recourse to support is absurd, and even 3 hour account lock would never fly. Even 5 minute account locks would never fly. You could still DOS anyone's account for whom you knew the username. And usernames aren't generally secret or particularly hard to guess.
And regarding the local attacks -
I pretty much agree with you here.
(Score: 2) by urza9814 on Wednesday May 06 2015, @12:25PM
Right, I mean you can't do it for something like Facebook or Gmail...I was talking more about the internal corporate network. I'd assume the password taped to the monitor in this story wasn't for someone's Gmail account. But at my office all our Unix and Linux systems, all the databases, all the local Windows logins...almost any internal systems lock you out after too many failed attempts. There's a couple that don't, but they're less critical and not externally accessible (ex: our ticketing system)
Actually this brings another point to mind as well...this would seem to present an interesting case against outsourcing your IT infrastructure to "the cloud". A cloud provider would never enable account locking because they don't want to deal with constant unlock requests, and they don't have a good way to prove that a user is who they claim to be anyway. But a local admin should have no problem handling that.
(Score: 2) by vux984 on Thursday May 07 2015, @02:33AM
I was talking more about the internal corporate network.
But at my office all our Unix and Linux systems, all the databases, all the local Windows logins...almost any internal systems lock you out after too many failed attempts. There's a couple that don't, but they're less critical and not externally accessible (ex: our ticketing system)
That seems backwards. The ones that AREN'T remotely accessible are at far less risk of DOS; its the ones that ARE externally accessible you can't use an account lockout on!!
And depending on the definition of critical, the ones that that ARE most critical are the ones you can not afford to be locked out of. Its only the relatively non-critical stuff that you can afford to fart around with the help desk for 20 minutes to get a locked account unlocked.
Actually this brings another point to mind as well...this would seem to present an interesting case against outsourcing your IT infrastructure to "the cloud".
Agreed. One well known disadvantage to the cloud is that your security and admin personal are often connected via exactly the same routes and network connections potential attackers are. That makes it a lot harder to kill their connection -- because you can very easily kill yours too in the process. If the server is in a rack in the next room, you can shutdown network interfaces. clean it, harden it, and bring it back online much easier.
(Score: 2) by urza9814 on Thursday May 07 2015, @12:54PM
Well, in our production environment *people* don't login to those systems, only software does. So you encrypt the password in the software config somewhere. It won't get locked out unless it's under attack. Of course, we have the same setup on all the test environments, so there you'll have people logging in, and periodically getting themselves locked out. But that's not really a problem.
Ah, yeah, I should have written that a bit different -- we don't really have any external systems of any significance. I work on retail pharmacy software, so we've got our website and we've got Outlook web access and that's all I can think of right now. I'm not sure if the email locks you out, but definitely all the systems where you could access the really important stuff -- like patient data, prescriptions, insurance info, that sort of stuff all locks after three attempts. So you might be able to brute-force your way into someone's store loyalty card account, but that's about it.
So a network like the train control systems this article discusses, there shouldn't really be any externally accessible systems. There's very little the public needs to interact with. So you should be able to put lockouts on pretty much everything.
(Score: 0) by Anonymous Coward on Wednesday May 06 2015, @02:59PM
Not if you combine it with an SMS unlock system (you can unlock your account by having an SMS sent to you using a phone number you've previously stored in the system, which contains a one-time unlock code; as bonus, you could have the user enter the phone number, but still only send the SMS if it matches the previously saved one; that both acts as additional — though not very strong — password, and as protection against people getting a new phone, but forgetting to update the number in the database). Then unlocking takes only slightly more time than normal login, but the attacker will have to wait until the user happens to need access to that account again.
And yes, you could also hack that system. But that's an order of magnitude more difficult than just sending random passwords from botnets, and will only be done by attackers who are really determined to get into your system; but that's not the type of attackers which are stopped by password policies anyway.
(Score: 2) by vux984 on Thursday May 07 2015, @02:19AM
Not if you combine it with an SMS unlock system (you can unlock your account by having an SMS sent to you using a phone number you've previously stored in the system
And then 5 minutes later the entire company is locked out again. How many times in one day are you going to SMS unlock your account before you realize letting a random person on the internet lock you out in the first place is too tiresome to tolerate.
You might as well just go two-factor auth, since you have to use SMS anyway to login. And that completes the circle ... why bother worrying overmuch about locking the account after 3 attempts if you are using 2 factor auth anyway?