3

Given that there are many password sniffing MitM scripts out there that comb traffic for key-phrases like "pass" and "password".

Why do manufacturers keep the same variable names and make it easy for the attackers?

Surely the manufacturers (of routers, etc...) could use the variable "pass" in the source code but change it to some randomised string specific to that device on release, thus making it nearly impossible to single out the password without manually combing through a large file of captured packets.

schroeder
  • 123,438
  • 55
  • 284
  • 319
aidan
  • 31
  • 3
  • 4
    Hi and welcome! This would be obscurity rather than true security. It would in the real world provide hardly any benefits as the attackers would (and often do) capture all form post variables anyway. – ISMSDEV Jul 23 '17 at 09:42
  • @ISMSDEV So they wouldn't do it to deter attackers? – aidan Jul 23 '17 at 09:46
  • 3
    @aidan E.g. an attacker could just filter out POST requests to, say, `login.php` and would still easily get the credentials without knowing the form field names. The correct solution is encryption, not obscurity. – Arminius Jul 23 '17 at 09:50

2 Answers2

3

Autofill. Most browsers now have password managers, which are arguably more secure than remembering your password as they allow you to have different passwords that are illegible for each site. How can a user remember that their Facebook password is "a!34-tU62-He4M", and their google password "e4T?-y5Bf-6gR6". Compound that with the number of accounts people have and it becomes insane. Now, if all a user needs to remember is their master password, and provided the passwords are stored securely, they can have unique passwords for each site that are secure.

Password managers can only work if they know what the input is. A field named "x1" means nothing to a password manager, and it won't capture or fill in data to it. A field however named "password" will be flagged.

zzarzzur
  • 1,112
  • 8
  • 8
  • You misinterpreted the question, i was asking why website developers use the ["name='pass'"](https://www.w3schools.com/tags/att_input_name.asp) tag instead of using a randomised string making it harder for the attacker to single out the password field. – aidan Jul 23 '17 at 14:50
  • 6
    @aidan I think you misinterpreted my answer. The reason why now is so autofill knows which field is the password and which is the email. How would your browser know that the box you selected is the password if it's name wasn't password. – zzarzzur Jul 23 '17 at 16:31
  • 1
    @zzarzzur Presumably by looking for an input type of `password`? Not that I think that this would be a good security measure, but I'm not sure if your answer is correct. I could be wrong though. – Conor Mancone Jul 24 '17 at 03:05
  • @ConorMancone Okay, we look for a input type of password. Now how about the email? Input type of email? Okay, now username. That's just a text input. How about webpages that use the password input for usernames? Those sites do exist. First name? Last name? Address? Phone number? All of these fields can be filled in by autocomplete. I'm not saying this is the only reason why, but it is a reason why. – zzarzzur Jul 24 '17 at 03:51
  • @zzarzzur ah no i meant that each router would be shipped with a unique name "number" if you will, that way the browser would still know where to put the password. It wouldn't change over time. – aidan Jul 24 '17 at 07:01
  • @zzarzzur I understand that looking at the input type doesn't work generally, but browsers already treat password fields differently because of their security needs. When it comes to autofill, I don't think browsers treat password fields like any other field, and as a result I think the name on a password field is probably meaningless for the browser autofill. – Conor Mancone Jul 24 '17 at 12:20
  • 1
    @zzarzzur Indeed, I ran a quick test with firefox. I made a dummy site with a login form, logged in and stored my password with the browser, and then logged back out. Then I edited the page to remove the name from the password field. After refreshing the browser still auto-filled the login form for me. I think this verifies my suspicion: browsers identify password fields by their type, and store login credentials by domain name. As a result autofill for passwords works regardless of the name of the input field. Thanks for making me dig! I'm happy to have learned this. – Conor Mancone Jul 24 '17 at 12:26
1

You're assuming an awful lot about router manufacturers: mainly, that they are good at best-security practices. Case in point: my router (a linkysys) doesn't have a name on the password field, because it turns the form into an ajax submission that passes the password over BASIC authentication. It doesn't do this over HTTPS (a terrible choice), and it also attempts to turn off autofill on the password field (another terrible security choice). (Now I remember why I bought a router compatible with open source firmware: time to go figure that one out...). So truly: don't assume that router manufacturers have any idea what they are doing when it comes to security. edit I had previously said the password on my router was encrypted client-side before sending. I realized that the security was so bad there was no way they were doing that. So I double checked. It wasn't encrypted. They were just base64 encoding the username/password combination to make it easier to transport.

As @ISMSDEV mentioned, your suggestion is just security through obscurity. As a general rule of thumb that is not the best method to secure anything. Security through obscurity can deter simpler automated attacks, so it isn't crazy to try it, so long as your application is otherwise secure. You certainly wouldn't want to worry about it as your only security method (which obviously isn't what you are suggesting).

However, all things in software involve a cost-benefit analysis. Introducing ad-hoc security methods is as likely to introduce more bugs (and more points for vulnerabilities) than anything else. More security is always good, but you need to make sure that any given security measure has real benefit. Adding in more code to maintain with marginal benefit is probably going to hurt security in the long run.

Presumably, most router manufacturers don't consider such a security feature to be worth the effort. Then again, they don't consider even basic security to be worth the effort. shrug

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • Yes my router goes along the same lines as yours, basic HTTP authentication, no SSL or TLS. – aidan Jul 24 '17 at 06:58
  • @aidan Then you definitely have the answer to your question. Your router doesn't even perform basic password security. I seriously doubt any real thought was given to security best-practices at all, aside from requiring a password to configure the device. To be fair, that is still more than what can be said for some IoT devices or even the first version of the connected jeep: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway – Conor Mancone Jul 24 '17 at 11:21
  • So what about routers aimed at business? Are they just as bad security wise or do you have to pay premium for anything remotely secure? – aidan Jul 24 '17 at 11:54
  • I think it is a good policy to never underestimate how badly companies in general screw up security. However, I don't actually know what my qualify as "commercial" grade networking equipment, and if it might be meaningfully better. Frankly, I doubt it. At the very least, I'm sure that most companies use the same software base for both their commerical and residential models (presuming there is a difference). So I suspect things like this are the same for both. – Conor Mancone Jul 24 '17 at 12:06