Sometimes they are necessary. They create special scenarios that don't seem to be handled very well.
These are some of the problems I have seen with them:
1) Login 1000 is reserved as the "Administrator", but not stored in the database table. What happens if I make a new login 1000 and assign it read only permission? Hopefully the application prevents that, but sometimes it does not.
2) Administrator Login still has the menu option to allow its password to be changed. It definitely should allow the default password to be changed, just make sure the old one doesn't work too. Otherwise changing the default password was pointless.
3) Administrator Login is stored in the database table, but it can be deleted or renamed. Now I lost my special user.
4) Administrator Login 1000 is enabled only when the userlogin table is empty. When a login is deleted it marks a deleted flag true so the audit history can be kept instead of deleting the row. If all users are deleted nobody can get into the software because it only checks if the table is empty instead of also checking if all users are marked deleted.
5) Some special logins have special passwords. They could be generated using a formula or some other method. Does the special password work correctly?
6) The special user uses a weak password and it cannot be changed. Why even make a special user if it will be insecure? They would be better off with no logins at all.
7) The special logins are stored separately from the regular logins; in a text file, in the Windows registry, or in an Access database.
8) New menus were added to the program, but they weren't added for the special user. Now the user is no longer an Administrator.
