[harshreality]

If everyone uses long random passwords and never reuses them elsewhere, maybe it's optimal for simplicity and server-side cpu usage. There's no difference (edit: should say advantage rather than difference) in salted passwords (salt + shorter-randompassword) compared to (longer-random-password); salts become unnecessary since you can effectively guarantee that two users won't share the same password if they're all random and separately chosen.

However, the real world called and it wants "suboptimal" choices back, for when users don't use good password hygiene.

[VLM]

"guarantee that two users won't share the same password"

routers with hard coded passwords in the config don't have users. Device passwords. Often the console/telnet and enable password are the same so there is "a" password.

Of course you could implement as a network admin a psuedosalted standard like our router password shall be prefixed with hostname, "hostnamereallylongcomplicatedpasswordthatsthesameforallhostnames" then rainbow tables will barf because each individual device password begins with a different hostname, even if all of them end with the same "l33tpass0rd" or whatever.

This is assuming you have a sensible hostname strategy, or even assign "real" hostnames to your routers. I suppose people like that who haven't caught up to that newfangled "DNS thing" could use a unique router ip addrs, although now we're assuming a sensible ip allocation scheme and network design. This is kind of reading like Dante, isn't it.

[tjoff]

Sure there is a difference. If there is another exploit that gets you hashed passwords from many thousand different routers you would be quite happy knowing that none of them were salted.

Also there is a huge difference between (salt + short-random-password) and (long-random-password) because the salt isn't nearly as confidential as the password and knowing it reduces the attack vector to (short-random-password), which is trivial to break for such poor (in this context) hash algorithm.