I've been working with Oracle Session Border Controllers and Enterprise Communications Brokers a lot recently, and I encountered what I think is a new bug (it's with Oracle for investigation).
After deploying some new ECB instances, I changed the login and enable passwords, per the Oracle ACLI guide ("secret login" and "secret enable" at the SSH prompt). I used randomly generated strong passwords which included limited special characters -- "#", "%", "?" and "!".
The ECB appliances use two passwords per username - one to log on to the unit, and one to 'enable' (admin mode for configuring them, similar to Cisco's enable mode).
On one appliance, the new password I generated for it was accepted without complaint when typed and retyped at the confirmation prompt. However, attempting to then authenticate a new session using this password resulted in immediate refusal by the appliance. It effectively denied access, with no recovery method. I had to flatten and redeploy the appliance!
After I was locked out, I tried all sorts of alternatives, seeing if the password had been partially saved or corrupted - seeing whether the password was truncated at the # symbol, whether the appliance replaced it with a space character, whether it omitted the # symbol when it committed it to memory, or whether it simply swapped it for another character. I must have tried a dozen or so possible variants before giving up.
Despite the documentation saying "do not use special characters", one normally expects a password change routine to immediately reject any invalid special characters on submission using string validation. This isn't a new concept. However, the ECB appliances seem to happily accept invalid characters, even though one of them causes a service-affecting bug.
I've previously set passwords including !, ? and % characters -- those are in use on other ECB appliances using the same software revision (and SBCs) and they work fine. I have only encountered this problem so far using # symbols.
I see conflicting information about acceptable non-alphanumeric symbols in passwords in the Oracle documentation. However, the fact that simply entering a # symbol as part of a new password when updating credentials can lock you out of admin access on a production system seems pretty bad.
I can reproduce the fault with a fresh OVA deployment of ECB PCZ2.2.0 GA (Build 53), so this seems like a serious bug which can end up with an administrator permanently and irreparably locking themselves out of their own system. I'm only glad I was setting the passwords prior to deploying a configuration!
If you're working with Oracle ECBs or SBCs, be very careful about which special characters you use in your strong passwords.