5 ms·

I have a WNDR 4700 and I can't replicate as described. However, I've also never trusted the stupid thing since it stores passwords in clear text (or at least is

I have a WNDR 4700 and I can't replicate as described. However, I've also never trusted the stupid thing since it stores passwords in clear text (or at least is happy to display them in clear text on one of its admin pages).

dgesang 13y ago
Even major browsers store/show passwords in clear text, can it be that wrong? ;)
- graue 13y ago
  That's different. Browsers need to show your password to external websites to prove to others that you're you. This requires storing the actual password. They expose saved passwords in the UI because if they didn't, it would create a false sense of security. There's always going to be some way to get the saved passwords, or the feature wouldn't work. The router admin interface only needs to check your password. It can do that by storing only a cryptographic hash, not the password itself.
  - darkmighty 13y ago
    I think they could however, as a default behavior, store each password encrypted individually using itself as a key, that way no plaintext passwords would need to be stored at all.
    - kcorbitt 13y ago
      Then you would have to type in the password each time you wanted to use it anyway. Not much sense in storing anything in that case. :)
      - dgesang 13y ago
        It does make a lot of sense, actually, as you need to remember only one master key instead of multiple login-password combinations.
        derefr 13y ago
        That's different from "using itself as a key", which is what the GGP said.
      - darkmighty 13y ago
        Yup that's right, my bad. I were thinking of a way of somehow not requiring input yet providing passwords without plaintext storage. What would actually work I guess would be storing a hash of <the password, a unique string provided through https auth>. So for the first time the browser would hash the pass and afterwards just provide the pass to the server as a hash without requiring input, acting as a normal pass to the server. However, that would either require some sort of universal agreement among browsers to work, which is tricky to require, or some browser-server protocol in which the browser would only carry such procedure to supported servers. If a supported server is accessed through a non-supported browser, the server itself would perform the hash. Probably too much of a hassle just in name of abolishing plaintext passwords on browsers, but I couldn't think of anything simpler. However, fun to imagine :) Obs: This would have the extra bonus of depriving knowledge of plaintext passwords to servers (in case they are compromised, the attacker would not get to try the pass across other services) and preventing password extraction through impersonation of webpages (although this is already guaranteed by https to some extent).
        entropy_ 13y ago
        If servers accepted a hash of a password instead of the actual password then the hash becomes the password. Ie, possession of the hash is equivalent to possession of the password since it can be used to authenticate. Therefore, this is no different than storing them in plaintext. Furthermore, it would mean that if the hashes got stolen because a server was compromised those could be used as passwords and that would make it pointless to hash them in the first place. In other words, no, that wouldn't work.
        dTal 13y ago
        And if you need to log in from a different computer? All you are suggesting is replacing one password with another, harder to remember password. The system where the server only stores salted hashes and hashes your password server-side every time you log in is called "good practice". If you're allowing dedicated protocols and hard-to-remember keys, just use public/private keys.
- xtreme 13y ago
  Browsers need to store the passwords in plaintext, because they need to populate the password field when you visit that website. However, you can store them encrypted using a master password and decrypt them once per session.
  - derefr 13y ago
    And, on OSX at least, every browser does this anyway, since the Keychain is right there to make use of and unlocking it is built into the OS. I'm really surprised Windows has no equivalent to this.
    - girvo 13y ago
      My issue with Keychain is that unlocking it once keeps it unlocked, and my sessions on my iMac last forever (I rarely turn it off or log off) Any ideas on the best way of tackling that? Perhaps I'm using it incorrectly?
      - derefr 13y ago
        You're using Keychain correctly, but using your computer's authentication system incorrectly. Desktop environments in general (in Windows, OSX, Linux, etc.) assume that you will lock your session whenever you are not present and in control of the computer. (Thus, Keychain locks when the session is locked.) This is currently a big hassle to do, but all other security on the system is built up around that concept. Really, PCs need something like TouchID. Or something like pairing to your phone, and then detecting it in proximity and prompting a TouchID confirmation from it. Phone goes out of proximity = computer locks.
        reginaldjcooper 13y ago
        > This is currently a big hassle to do ⇧⌃⏏ is insufficient?
        derefr 13y ago
- bigiain 13y ago
  A browser has to be able to supply clear-text passwords to websites, so strong hashing and discarding the clear-text won't work in their use-case. Your router only need to authenticate your password, so it _should_ be using bcrypt/scrypt/pbkdf2 to hash the password and not storing it anywhere in clear-text.
  - dgesang 13y ago
    Anyone noticed the smiley? Still, not protecting user passwords with a master-key makes it way too easy to read them. B2T now.
girvo 13y ago
I had fun freaking out my not-so-tech-savvy-but-exceedingly-paranoid (tin foil paranoid) uncle: He bet me $50 I couldn't crack his WiFi password. He let me use his iMac that was already connected. I hopped onto the Admin page for the router. Had a password, which make sense. I submitted a test password, and there was no page-refresh or network activity... hm. Must be just in the Javascript... Sure enough, it was obfuscated, but the password was in the damned HTML and easy enough to find. I got $50, and the priceless look of horror on my uncle's face. I then explained to him that physical access to a computer usually equals "Game Over" ;)
- MichaelGG 13y ago
  But you didn't have physical access to the router. Setting aside that you could probably dump it out of memory if you had root on the OSX box, the router shouldn't have coughed it up so easily if it was supposed to be secure.
  - girvo 13y ago
    Oh, that was supposed to be my point if I didn't make it clearly enough: a router should NEVER have been programmed to do that.

dgesang 13y ago

Even major browsers store/show passwords in clear text, can it be that wrong? ;)

graue 13y ago
That's different. Browsers need to show your password to external websites to prove to others that you're you. This requires storing the actual password. They expose saved passwords in the UI because if they didn't, it would create a false sense of security. There's always going to be some way to get the saved passwords, or the feature wouldn't work. The router admin interface only needs to check your password. It can do that by storing only a cryptographic hash, not the password itself.
- darkmighty 13y ago
  I think they could however, as a default behavior, store each password encrypted individually using itself as a key, that way no plaintext passwords would need to be stored at all.
  - kcorbitt 13y ago
    Then you would have to type in the password each time you wanted to use it anyway. Not much sense in storing anything in that case. :)
    - dgesang 13y ago
      It does make a lot of sense, actually, as you need to remember only one master key instead of multiple login-password combinations.
      - derefr 13y ago
        That's different from "using itself as a key", which is what the GGP said.
    - darkmighty 13y ago
      Yup that's right, my bad. I were thinking of a way of somehow not requiring input yet providing passwords without plaintext storage. What would actually work I guess would be storing a hash of <the password, a unique string provided through https auth>. So for the first time the browser would hash the pass and afterwards just provide the pass to the server as a hash without requiring input, acting as a normal pass to the server. However, that would either require some sort of universal agreement among browsers to work, which is tricky to require, or some browser-server protocol in which the browser would only carry such procedure to supported servers. If a supported server is accessed through a non-supported browser, the server itself would perform the hash. Probably too much of a hassle just in name of abolishing plaintext passwords on browsers, but I couldn't think of anything simpler. However, fun to imagine :) Obs: This would have the extra bonus of depriving knowledge of plaintext passwords to servers (in case they are compromised, the attacker would not get to try the pass across other services) and preventing password extraction through impersonation of webpages (although this is already guaranteed by https to some extent).
      - entropy_ 13y ago
        If servers accepted a hash of a password instead of the actual password then the hash becomes the password. Ie, possession of the hash is equivalent to possession of the password since it can be used to authenticate. Therefore, this is no different than storing them in plaintext. Furthermore, it would mean that if the hashes got stolen because a server was compromised those could be used as passwords and that would make it pointless to hash them in the first place. In other words, no, that wouldn't work.
      - dTal 13y ago
        And if you need to log in from a different computer? All you are suggesting is replacing one password with another, harder to remember password. The system where the server only stores salted hashes and hashes your password server-side every time you log in is called "good practice". If you're allowing dedicated protocols and hard-to-remember keys, just use public/private keys.
xtreme 13y ago
Browsers need to store the passwords in plaintext, because they need to populate the password field when you visit that website. However, you can store them encrypted using a master password and decrypt them once per session.
- derefr 13y ago
  And, on OSX at least, every browser does this anyway, since the Keychain is right there to make use of and unlocking it is built into the OS. I'm really surprised Windows has no equivalent to this.
  - girvo 13y ago
    My issue with Keychain is that unlocking it once keeps it unlocked, and my sessions on my iMac last forever (I rarely turn it off or log off) Any ideas on the best way of tackling that? Perhaps I'm using it incorrectly?
    - derefr 13y ago
      You're using Keychain correctly, but using your computer's authentication system incorrectly. Desktop environments in general (in Windows, OSX, Linux, etc.) assume that you will lock your session whenever you are not present and in control of the computer. (Thus, Keychain locks when the session is locked.) This is currently a big hassle to do, but all other security on the system is built up around that concept. Really, PCs need something like TouchID. Or something like pairing to your phone, and then detecting it in proximity and prompting a TouchID confirmation from it. Phone goes out of proximity = computer locks.
      - reginaldjcooper 13y ago
        > This is currently a big hassle to do ⇧⌃⏏ is insufficient?
        derefr 13y ago
bigiain 13y ago
A browser has to be able to supply clear-text passwords to websites, so strong hashing and discarding the clear-text won't work in their use-case. Your router only need to authenticate your password, so it _should_ be using bcrypt/scrypt/pbkdf2 to hash the password and not storing it anywhere in clear-text.
- dgesang 13y ago
  Anyone noticed the smiley? Still, not protecting user passwords with a master-key makes it way too easy to read them. B2T now.

girvo 13y ago

I had fun freaking out my not-so-tech-savvy-but-exceedingly-paranoid (tin foil paranoid) uncle: He bet me $50 I couldn't crack his WiFi password. He let me use his iMac that was already connected. I hopped onto the Admin page for the router. Had a password, which make sense. I submitted a test password, and there was no page-refresh or network activity... hm. Must be just in the Javascript... Sure enough, it was obfuscated, but the password was in the damned HTML and easy enough to find. I got $50, and the priceless look of horror on my uncle's face. I then explained to him that physical access to a computer usually equals "Game Over" ;)

MichaelGG 13y ago
But you didn't have physical access to the router. Setting aside that you could probably dump it out of memory if you had root on the OSX box, the router shouldn't have coughed it up so easily if it was supposed to be secure.
- girvo 13y ago
  Oh, that was supposed to be my point if I didn't make it clearly enough: a router should NEVER have been programmed to do that.