-
Accessing the application
-
Application security
-
Devices and communication protocol
-
Application access control levels
-
Employees, departments and device users
-
Time & Attendance Functionality
-
Access control
-
Batches & payroll integration
-
Binary City Time API (Application Programming Interface)
-
Binary City Time integration with BioTime Technical Documentation
User security
User security
Binary City Time is password protected, therefore you will need to be an existing user with a known username and password, to gain access to the service. When logging in, it will be necessary to enter both you email address (which will act as your username) as well as your password.
As an additional layer of security, 2-step authentication is required to access the system. Once you've logged in with a known username and password, the system will email the user a unique 6 digit code, which is needed to gain access to the application.
A password policy is automatically applied to all clients and can be configured with the following options:
Minimum password length
This setting determines the minimum number of characters a password should contain.
The default value is 8.
For example, if the Minimum Password Length is set to 6, then the password must contain at least 6 characters.
Minimum Password age
This setting determines the minimum number of days a password must be in use, before it can be changed. Only when the minimum password age expires, users are allowed to change their password. It ensures that users don't change their password too often. The value can be set between 0 (disabled) and 720 days.
The default value is 1.
For example, if the Minimum Password Age is set to 10, then the user cannot changed his/her password for 10 days after the last password change.
This setting is used to ensure the effectiveness of Enforce Password History setting. If the Minimum Password Age is set to 0 (disabled), then the user can change his/her password until the value set for Enforce Password History is reached and reuse his/her favorite old password. By setting the Minimum Password Age to a certain value, a user cannot change his/her password often enough to render the Enforce Password History setting ineffective.
The value for Minimum Password Age should always be less that the Maximum Password Age.
Maximum password age
This setting determines the maximum number of days a password can be used. Once the Maximum password age expires, users must change their password. It ensures that users don't stick with one password forever. The value can be set between 0 (disabled) and 720 days.
The default is 360.
For example, if the Maximum Password Age value is set to 60, then the user must change his/her password after every 60 days. If the value is set to Disabled, then the password never expires, and the user is not required to change his/her password ever.
Enforce password history
This setting determines the number of new passwords that have to be set, before an old password can be reused. It ensures that old passwords are not continuously by users which will render the Minimum Password Age policy setting useless.
The default value is 10.
For example, if the Enforce Password History value is set to 10, then the user must set 10 different passwords when the password expires, before setting his/her password to an old value.
If the value is set to Disabled, then the password history is not remembered and the user can reuse their old password when their password expires.
This setting determines whether the password must meet the complexity requirements specified. If this setting is enabled, passwords must meet the following requirements.
Not contain the user's account name or part of the user's full name that exceed two consecutive characters
The password contains characters from at least three of the following four categories:
English uppercase characters (A - Z)
English lowercase characters (a - z)
Base 10 digits (0 - 9)
Non-alphanumeric (For example: $, #, or %)
By default, this setting is disabled
We have built the following security module to ensure that credentials remain private.
On the client side (Browser and Local Area Network):
With private and public keys, using OpenSSL, HTML login form, data is encrypted before posted to server, and decrypted server-side, to ensure data is not compromised locally.
Server-side (Where Binary City Time is hosted):
Data is send/posted to an HTTPS connection (via secure port).
One way string-hashing, with a cost higher than 10.
Salt is generated by means of pseudo-random string of bytes, of length longer than 15.
After 4 failed attempted logins, an account is locked.
Only authenticated users with the required access, will be able to grant access to or load other users on Binary City Time.
There are no comments for now.