1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

why is http_passwd not stored with md5crypt?

Discussion in 'Tomato Firmware' started by Mangix, Jan 27, 2013.

  1. Mangix

    Mangix Networkin' Nut Member

    the stock linksys firmware uses it. dd-wrt uses it. probably openwrt. why not tomato. seems like an easy thing to add...

    i tried searching for an answer to no avail.
     
  2. gfunkdave

    gfunkdave LI Guru Member

    Personally, I prefer it this way. It provides a nice way to make sure you know the password if needed.
     
  3. Mangix

    Mangix Networkin' Nut Member

    I don't like that argument since if you have ssh/telnet access to the router in the first place, http_passwd is both viewable and changeable. Meaning just run md5crypt and paste the result. Although i assume the easy solution is to just delete the entry and have it reset to default.
     
  4. koitsu

    koitsu Network Guru Member

    FWIW, and it's not much these days, but I agree with Mangix. That string should almost certainly be encrypted; I don't care if it's des or md5 or whatever else.
     
  5. Mangix

    Mangix Networkin' Nut Member

    ahem: http://hashcat.net/oclhashcat-plus/ <-- Performance section

    An AMD Radeon HD 7970 can do 79 million attemps per second for a descrypt key and almost 4 million for md5crypt.​

    Ideally, bcrypt would be a good solution but with its 4 kB internal state, may be too slow.

    Then again, this is ultra paranoia...​
     
  6. gfunkdave

    gfunkdave LI Guru Member

    If you have ssh or telnet access to the router, then you already have the password.
     
  7. Mangix

    Mangix Networkin' Nut Member

    Not if public key authentication is used.

    I guess the answer boils down to "It's been this way since the beginning so why bother changing it?" Probably because everyone else has changed. I guess I'll write a patch someday...
     
  8. RMerlin

    RMerlin Network Guru Member

    If you have SSH access to the router, then you can change that password for anything you'd like using the nvram command. That amounts to pretty much the same thing.
     
    koitsu likes this.
  9. koitsu

    koitsu Network Guru Member

    No, I doubt that is the answer. The complexity here lies in how to implement the change. Would you like me to talk at length about all the nuances involved?

    Remember: I am for changing this (to DES, MD5, SHA1, SHA256, whatever -- I don't care, anything is better than plaintext**). You have my full support. But the nuances involved in this change -- more specifically, how to handle someone rolling back from the version that uses encryption to the version that doesn't -- is very sensitive/complex to deal with. Nuances, like I said.

    **: I couldn't care less if a GPU can bust these things at insane speeds. Let me make that point loud and clear. A year from now they'll be able to bust SHA1 even faster. Two years from now, SHA256. Don't become obsessed with this aspect of it -- the points gfunkdave and RMerlin are valid here.

    Furthermore, public SSH key authentication has nothing to do with the what you're talking about -- if you authenticate using an SSH key, you wouldn't be using http_passwd for anything (and if you can SSH into the router, like gfunkdave said, then you have other problems that easily supercede/trump any concerns over plaintext NVRAM variables) -- and as I commented in another thread people should not be using passwordless SSH keys (use an SSH agent/Pageant/etc. you ninnies!)
     
  10. RMerlin

    RMerlin Network Guru Member

    That part would be easy to handle actually - use a different nvram var to store the encrypted password. Newer versions would only use the new var, and old firmwares would use the old one - meaning it would revert to default password if the setting doesn't exist (in case you had never run an older firmware before).

    But yeah, that isn't the point. It's more about the "what difference would it really make" than anything else IMHO.
     
  11. Mangix

    Mangix Networkin' Nut Member

    Can't say I've considered this too much as newer versions of tomato(shibby or toastman builds) work better for me than what came before.

    That being said, my main motivation for using crypt(3) in http_passwd is to flash between firmwares(stock, dd-wrt, etc...) easily. Of course for convenience sake it's possible to make the variable work with plaintext and hashed passwords but yeah, old versions of tomato are an issue.

    Anyway, might as well forget about this since it won't happen any time soon(from what I can tell).
     
  12. koitsu

    koitsu Network Guru Member

    ...except now you have two NVRAM variables that in effect represent the same thing, and historical documentation all refers to http_passwd. The result of introducing a new variable will be years of this:

    Q: Uhh, what is this http_passwd variable?
    A: It's not used any longer, use http_passwd_encrypted.
    Q: Then why is it still in NVRAM? Why didn't someone nvram unset http_passwd?
    A: Because if you roll back...........
    Q: Okay, I'll unset it.
    {4 weeks later}
    Q: Hi I downgraded my firmware and now I can't log in to my router any more. WTF?

    We have to be pragmatic about this. :-/

    So, Mangix, how did DD-WRT solve this dilemma?

    Mangix's point is that the string should be encrypted. And I am in full 100% support/agreement with him on that point. As far as what kind of difference it makes, that's easy to answer: increased security with no ill-effects. I say this knowing quite well that if someone already has access to the router to issue nvram show then the last of their worries is whether or not the variable is encrypted. :) The only complexity it introduces is how to deal with the NVRAM variable situation. I get the impression DD-WRT and others just said "stuff it, we'll encrypt it, and if you have to roll back you'll need to do 30/30/30" in which case developers and end-users will need to chime in + weigh pros/cons to that model.
     
  13. Mangix

    Mangix Networkin' Nut Member

    I skimmed through the tomato code a while back and saw that if http_passwd is missing, it defaults to using admin as the password.

    As for dd-wrt, I have no idea. I haven't read the code since it's almost impossible to compile(too many working parts. atheros builds are also impossible since they're using a private ath9k driver). It could have been this way since the beginning.

    Note that if you do 'cat /etc/shadow' in tomato, the password is hashed using md5crypt. Actually in dd-wrt, http_passwd and the string in /etc/passwd(no shadow file on dd-wrt for some reason) are the exact same.
     
  14. apnar

    apnar Network Guru Member

    Another consideration is when the information is outside of the router. For example in a config backup, initial setup script, or even posting nvram output to the forum for help. It's not perfect having it MD5ed but it's a much better then having it plain text. I've had to be more careful with where and how I keep my configs since switching from dd-wrt to tomato for this very reason.

    As to rollback options, I'm in the f-it camp. Give folks notice and put a nice big warning up (dd-wrt doesn't even recommend keeping settings even for small upgrades let alone downgrades, they push for you to reconfigure everything by hand every time).

    Actually now that I think about it, assuming you use the (very insecure but better than nothing) unsalted MD5 (which is what dd-wrt used last I looked) people could still rollback just fine. They'd just need to MD5 their old password themselves to be able to login to the rolled back version. Once logged in they could reset. This should of course be tested and make sure there isn't some character limit or such.
     
  15. Mangix

    Mangix Networkin' Nut Member

    Typical dd-wrt string: $1$fVLnh1iH$Qp7Auig3LpUNWYx6fplpp1 <--password is password
    $1$ indicates md5crypt. after that the salt and after the third $ is the hash.
    As for having this string in nvram dumps, do note that md5crypt is an extremely fast hash to run time-memory trade offs on. Having it posted online is still a bad idea.
    I would love to backport bcrypt and see how it performs on various routers, but it might be problematic since it requires quite a bit of RAM.
     
  16. godyang

    godyang Serious Server Member

    How about using two variables for compatibility? We can use a default password at least when we roll back firmware to the version that doesn't support encryption.

    e.g.
    • http_passwd: plaintext password
    • http_passwd_enc (or whatever): SHA1ed password (I prefer SHA1 because it's stronger :))
    Case 1.
    If only http_passwd exists,
    New firmware will convert http_passwd to http_passwd_enc, delete the old one, and use http_passwd_enc.

    Case 2.
    If only http_passwd_enc exists,
    This is an ideal state of new firmware.

    Case 3.
    If both http_passwd and http_passwd_enc exist,
    A new firmware will delete http_passwd, and use http_passwd_enc instead.

    Case 4.
    None of they exists,
    Default password will be used.
     
  17. sarelc

    sarelc Addicted to LI Member

    If that is the case, why not remove the http_passwd variable when the user flashes a new firmware and have Tomato do the same on first run?

    The first action would cover users downgrading to a non-encrypted build from Tomato's GUI. The second would prevent issues when flashing an build via TFTP, or software such as Asus' Upgrader (although I suppose the encryption function could simply exit if the existing password is plaintext).

    As for downgrading from a build with encryption to one without AND using a software program or TFTP... These seem like the most uncommon cases IMHO, but that doesn't change the fact that only the aforementioned app (to generate the encrypted password string) would resolve the problem. Keying it could be problematic however, maybe due to the string's length or illegal characters.
     
  18. mstombs

    mstombs Network Guru Member

    I am not to bothered about how password is stored due to reasons above - if you have cmd line access you can do anything. But surely we have to disable insecure http web logins anyway as the password is on the wire in plaintext? I happen to use https on non-standard port just to free the usual ones for other use - does anyone know how to sort some signing out so that browsers don't report security errors when connecting to https?
     
  19. Mangix

    Mangix Networkin' Nut Member

    Generate a TLS certificate, add it to tomato, and then make that certifcate trusted by your OS. I've done this with several websites.

    A TLS certificate must be generated as the browser will complain if the URL in the certificate does not match the website name(not sure what the default name is in tomato's certificate).
     
  20. sarelc

    sarelc Addicted to LI Member

    To bypass the warning, you will need to install the router-generated certificate into the credential store on your computer (easily googled). Be aware that this can expose you to additional security threats - someone with the proper skills or software could download the certificate and use it to spoof other secure sites that you use.
     
  21. raj chippy

    raj chippy Reformed Router Member

    Thank you. nvram show helped me recovered my http password.
     

Share This Page