HANK@TAUNIVM.BITNET (Hank Nussbacher) (09/10/90)
I am not sure if this a feature or a bug, but the cisco configure processor preserves trailing blanks. This causes the nasty problem of a password typed in as "XYZ " appearing as XYZ but actually needing "XYZ " to work (note the trailing blank). Users are warned to watch their trailing blanks when updating their passwords. This makes for an excellent security feature (have the hackers guessing how many trailing blanks exist) but I would prefer that this feature be removed in a future release. Hank
dougm@ico.isc.com (Doug McCallum) (09/11/90)
In article <25934@boulder.Colorado.EDU> HANK@TAUNIVM.BITNET (Hank Nussbacher) writes: >I am not sure if this a feature or a bug, but the cisco configure processor >preserves trailing blanks. This causes the nasty problem of a password >typed in as "XYZ " appearing as XYZ but actually needing "XYZ " to work >(note the trailing blank). A minor related complaint is that the "enable-password" command doesn't need to be entered as a complete name. "enable" is sufficient. I got caught by this when enabling CLNS via the terminal configuration and transposed "clns enable" to "enable clns". It took a while to figure out what I did. It makes for great fun trying to figure out what happened when you can't become enabled and the new password was written to NVRAM. I think the enable-password should be required to be typed in completely to avoid catching people by surprise. Doug McCallum Interactive Systems Corp. dougm@ico.isc.com
BILLW@mathom.cisco.com (WilliamChops Westfield) (09/11/90)
A minor related complaint is that the "enable-password" command doesn't
need to be entered as a complete name. "enable" is sufficient. I got
caught by this when enabling CLNS via the terminal configuration and
transposed "clns enable" to "enable clns". It took a while to figure out
what I did. It makes for great fun trying to figure out what happened when
you can't become enabled and the new password was written to NVRAM.
You can always delete a fogotten enabled or line-zero password by installing
the "debug" jumper on the CPU card. This causes the system to come up in
diagnostic mode, which doens't read the NVM. Then you can erase the NVM
and start over.
In 8.2, "enable" is a command distinct from "enable-password", so entering
"enable clns" won't cause this problem any more.
Bill Westfield
csico Systems.
-------fortinp@bcars223.bnr.ca (Pierre Fortin) (09/11/90)
In article <1990Sep10.200259.400@ico.isc.com>, dougm@ico.isc.com (Doug McCallum) writes: > In article <25934@boulder.Colorado.EDU> HANK@TAUNIVM.BITNET (Hank Nussbacher) writes: > >I am not sure if this a feature or a bug, but the cisco configure processor > >preserves trailing blanks. This causes the nasty problem of a password > >typed in as "XYZ " appearing as XYZ but actually needing "XYZ " to work > >(note the trailing blank). I would like to side with the "bug" group, but I can't remember the answer we got on this one when we received our first "baby" router about a year ago. In our case, we created the config file on an IBM mainframe with fixed-length records (padded with spaces). The problem was discovered when we created the config file on a Sun and it worked. > > A minor related complaint is that the "enable-password" command doesn't need > to be entered as a complete name. "enable" is sufficient. I got caught > by this when enabling CLNS via the terminal configuration and transposed > "clns enable" to "enable clns". It took a while to figure out what I did. > It makes for great fun trying to figure out what happened when you can't > become enabled and the new password was written to NVRAM. In our case, one of our remote sites was trying to reconfigure the device connected to the console port and inadvertently caused "enable xxxx" (where xxxx was some command for the terminal which I forget). Fortunaetly, the person who did this managed to recall what he did after some probing questions. > > I think the enable-password should be required to be typed in completely > to avoid catching people by surprise. I agree! > > Doug McCallum > Interactive Systems Corp. > dougm@ico.isc.com Pierre Fortin fortinp@bnr.ca Yeah I know; still no signature...