Hashed passwords
126
There is also the problem that two people using the same password end up with the same hash, and so can see
that the other person is using the same password.
To solve this, we use salt. Salt is simply a number of random bytes. These are appended to the end of the
original data before making a hash. This means the hash is not just of a password, but of a password and a
random string (the salt).
The salt is stored, along with the hash. This means it is possible to check a password by appending the salt and
calculating the hash and checking it matches the stored hash.
The password hashes all have an option of salt. If making your own password we recommend the latest hash
method and as much salt as allowed. The salt should be random.
The OTP seed is scrambled using a separate salt on the same password, else the encryption would simply be
using the hash you see in the
password
field, which would not be very secure!
G.2. One Time Password seed hashing
The configuration also holds the OTP seed used for One Time Password authenticator codes. However, this is
stored in an encrypted format so that the seed cannot be accessed. This is especially important as the OTP seed
allows the OTP sequence to be generated, not simply checked (as is the case with a password hash).
The issue with encrypting the OTP seed is that the FireBrick has to be able to decrypt it so as to check the OTP
sequence used. To ensure that no secret encryption key is embedded in the FireBrick firmware, the encryption
is done using the users password. Once again, this means that it is important to have a good password. This
system means that the password hash and encrypted OTP seed can be saved, and restored and even moved to
another FireBrick configuration if needed without ever having to know the seed or password itself.
Caution
This means that if someone knows (or finds out) the password and has access to the configuration file
then they could extract the OTP seed and use it to log in, even though they do not have the OTP device/
app. For this reason it is important to keep the password and OTP seed data in the configuration safe.
You can enter a new OTP seed in to the
otp-seed
field in the config, if you wish. This should be a BASE32
string (which is the common format for usch strings). If the seed is for 60 second periods not the default 30
then append /60. If the seed is not for 6 digit codes, you can add a time (/30 or /60) and then /N where N is the
number of digits (4-8). Once saved you will see the seed changes to a base64 coded string. If you do this you
should immediately test the authenticator by having the user log in. Until then, the seed is not encrypted in the
configuration and could be recovered. Once you have logged in, if you normally save / archive the config, this
would be a good time to ensure you have the encrypted version saved.
Note
The old OTP system used this field (called just
otp
) as the serial number of a separately stored OTP
seed that was not held in the config. This is no longer supported, but if you have such a configuration
you may see simply the serial number in this field until the user first logs in and it is replaced with
the encrypted OTP seed.
Once encoded the format is a
#
followed by base64 coding of a series of bytes. If making a configuration file
independantly then you can generate the seed data directly if you wish. The format is as follows.
• 1 byte: total length of data including this byte
• 1 byte: seed type 0xDT where D=digits and T is time in 10 seconds, so 0x63 is normal for 6 digits every
30 seconds.
• 1 byte: hash type, 0-15 means not encrypted but space for up to 15 bytes of salt. 32-47 means SHA256 hash
encrypted with up to 15 bytes of salt.
Содержание FB6402
Страница 1: ...FireBrick FB6402 User Manual FB6000 Versatile Network Appliance...
Страница 2: ......
