![]() The time interval must be between 1 and 60 seconds. A non-standard value can be configured in case a different time-step value must be used. Set interval between token refreshes to S seconds.īy default, time-based tokens are generated every 30 seconds. This will permit for a time skew of up to 4 minutes between client and server.ĭisable window of concurrently valid codes. This allows for a time skew of up to 30 seconds between authentication server and client.įor example, if problems with poor time synchronization are experienced, the window can be increased from its default size of 3 permitted codes (one previous code, the current code, the next code) to 17 permitted codes (the 8 previous codes, the current code, and the 8 next codes). In order to compensate for possible time-skew between the client and the server, an extra token before and after the current time is allowed. w, -window-size= Wīy default, a new token is generated every 30 seconds by the mobile application. This restricts the user to one login about every 30 seconds, but it increases the chances to notice or even prevent man-in-the-middle attacks. (Dis)allow multiple uses of the same authentication token. Those settings are only relevant for time-based one-time-password (TOTP): -D, -allow-reuse, -d, -disallow-reuse W, -minimal-windowĭisable window of concurrently valid codes. The window size must be between 1 and 21. In order to decrease the likelihood of synchronization problems, this window can be increased from its default size of 3. This accounts for generated-but-not-used tokens and failed login attempts. Those settings are only relevant for counter-based one-time-password (HOTP): -w, -window-size= Wīy default, three tokens are valid at any one time. t, -time-basedįrom this choice depends the available options. The main option consists of choosing the authentication token type: either time based or counter-based. Please note that this feature might not be available in all builds of the Android application.Įach time the user logs into the system, he will now be prompted for the TOTP code (time based one-time-password) or HOTP (counter-based one-time-password), depending on options given to google-authenticator(1), after having entered its normal user id and its normal UNIX account password. Then, the user checks that the displayed key's verification value matches the one provided by google-authenticator(1). To do that, the user must click-and-hold the added entry on its Android system until the context menu shows. In either case, after the key has been added, the verification value should be checked. Alternatively, the alphanumeric secret key is also outputted and thus can be manually entered into the Android Google Authenticator application. If the system does not have this library, google-authenticator(1) outputs an URL that can be followed using a web browser. If the system supports the libqrencode library, a QRCode will be shown, that can be scanned using the Android Google Authenticator application. By default, this secret key and all settings will be stored in ~/.google_authenticator. The google-authenticator(1) command creates a new secret key in the current user's home directory. ![]() If no option is provided on the command line, google-authenticator(1) will ask interactively the user for the more important options. Initialize one-time passcodes for the current user Synopsis
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |