Password Encoding Overview
Archibus Web Central can use different password encodings:
- Plaintext – Default encoding that Archibus ships with, so the sample database and new projects load and run.
- Archibus-encoding – Archibus 2.0 encoding, in use for all of the Web Central releases.
- bcrypt – Password hashing function, designed by Niels Provos and David Mazières, based on the Blowfish cipher. Besides incorporating a salt to protect against rainbow table attacks, bcrypt is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power.
- Tailored encoding – If you are familiar with Spring Security, you can substitute your own encoding, such as MD5.
Existing Methods for Password Encoding
- Archibus Client/Server – If you use security on Archibus Client/Server against the same project database, you must use plaintext encoding, or Archibus-encoding. Beginning with V.25.1, Archibus Client/Server is discontinued.
- Mixed encodings – Archibus Web Central, V17.1 and earlier, allows you to use plaintext encoding for some user accounts, and Archibus-encoding for others. Archibus Web Central, V17.2 and later, require you to use consistent encoding. If you have mixed encoding, refer to instructions below to change password encodings, to encrypt your passwords consistently.
- Old encoding – The current Archibus-encoding is known as v2.0. Prior to Web Central, Archibus databases supported an earlier encryption method – v1.0 – which Web Central does not support. If you upgrade an older database to use Web Central, you must reenter plaintext passwords for users, and then re-encrypt them.
Changing Password Encodings
In order to enforce consistent password policies, Archibus requires you to have one consistent encoding for all passwords. You establish this encoding in the password-encoder.xml before you start Web Central, and at that point, all legal passwords must be in that current encoding.
In order to achieve the desired level of security on passwords, Archibus also now supports encodings that cannot be reversed, meaning that once a password is encrypted, you cannot retrieve the original password. As such, in order to change encodings, you must issue a new password to all users.
For this reason, Archibus has features to:
- Bulk-generate unique plaintext password for each user
- Email plaintext passwords that must be changed on first login
- Bulk-encrypt plaintext passwords
These are typical transitions, and the transition method you would use:
- Plaintext to Archibus-encoding – Since your current passwords are not encrypted, you can simply encrypt them. End user can log in with the same password, as the password's storage format has changed, but the original password has not changed.
- Plaintext to bcrypt – Since your current passwords are not encrypted, you can simply encrypt them. End users can log in with the same passwords.
- Archibus-encoding to bcrypt – Since your passwords are encrypted, you must generate new passwords for your users, email them to your users, then encrypt the new passwords.
- BCrypt to Archibus-encoding – Since your passwords are encrypted, you must generate new passwords for your users, email them to your users, then encrypt the new passwords.
See also: