Login for Endpoints (available in SecureAuth IdP version 9.2+ only) adds SecureAuth’s Multi-Factor Authentication to the Windows desktop and remote server login experience, and the Mac desktop login experience. This product was introduced in SecureAuth IdP version 9.2 and supports these authentication methods:. Timed Passcode. Voice Call. Passcode sent via SMS / Text Message. Passcode sent via Email.

1. Secureauth Download For Windows 10
2. Secureauth Passcode For Microsoft Windows
3. Secureauth Authenticate App

One-time Passcode via Push Notification. Login Notification via Push Notification. YubiKey HOTP Device Passcode. Passcode from Help Desk NOTE: Methods delivered via Push Notification require the use of the In addition to the supported Multi-Factor Authentication methods, Login for Endpoints supports these setups / features for Windows and / or Mac. DISCLAIMERS:. Login for Windows does not support non-domain joined devices.

Issues pertaining to account synchronization are the responsibility of the customer and not SecureAuth. Login for Endpoints ONLY supports the samAccountName login name format; userPrincipalName (UPN) is not supported. Note that UPN is supported at login, but if using a non-AD profile store containing OATHSeed/OATHToken/PNToken but not samAccountName, then the Multi-Factor Authentication lookup will fail and the user will not be able to use other Multi-Factor Authentication methods. 1. Ensure SecureAuth IdP v9.2 or later is running and is using a SHA2 (or greater) certificate. Create a New Realm or access an existing realm on which more than one Multi-Factor Authentication is required.

NOTE: This realm should not be configured for Single Sign-on. Configure the following tabs on the Web Admin in preparation for configuring Login for Endpoints:. – the description of the realm and SMTP connections must be defined. – an enterprise directory must be integrated with SecureAuth IdP.

– the way in which users will access the target must be defined. – the Multi-Factor Authentication methods that will be used to access the target must be defined. – the target resource or post authentication action must be defined.

– the logs that will be enabled or disabled for this realm must be defined 4. Ensure target end-user machines are running any of the following supported OS versions. Active Directory Profile Configuration on the Mac The end-user Active Directory profile must be accurately configured on the Mac so that the endpoint can retrieve the AD end-user profile during the login process. Preconfigured Enterprise WiFi System Level Policy In an enterprise WiFi environment, before setting up Login for Mac on end-user workstations, the system level policy must be configured to allow the Mac to connect to the enterprise WiFi.

This setup lets Login for Mac fetch the OATH seed which is used to authenticate the end-user. Prevention of YubiKey Device Usage Conflicts If an end-user is already using a YubiKey device for YubiKey Multi-Factor Authentication on a SecureAuth IdP realm, the OATH seed and associated YubiKey device must be removed from the end-user's account in order to prevent a conflict when the end-user attempts to use a YubiKey device for HOTP authentication. (See the steps under End-user Multi-Factor Authentication in the YubiKey Multi-Factor Authentication Configuration Guide to remove the YubiKey device from the user account profile.).

Network Setup Issues Matching Active Directory Profiles Required Active Directory must include an account profile for each end-user, and that profile must match the AD profile set up on the Mac in order for the Mac endpoint to retrieve the AD profile. Login for Endpoints Installer Misconfiguration Edits Made in config.json File If the configured config.json file is edited, caution must be taken to ensure Unicode characters — instead of UTF-8 charcters — are not entered and saved in the file. This scenario might occur if text is copied from another source and pasted into the file, and could result in an end-user being locked out of the Mac due to a misconfigured endpoint. End-user Mac Configuration Issues Misconfigured Active Directory Profile on Mac If the end-user's new Mac has a misconfigured Active Directory account profile, the endpoint will not be able to retrieve the end-user's AD profile to complete the login process. Lockout with Secure, Automatic Enterprise WiFi Endpoint Connection If the endpoint is set to automatically connect to a secure, enterprise WiFi, and has not yet been configured to connect to a SecureAuth IdP realm, then the end-user will be locked out of logging on the Mac.

In this scenario, the Mac may need to be reset by the administrative user who can bypass the login endpoint in order to reset the machine. Lockout without OATH Seed for YubiKey HOTP Device or Network Connectivity If a YubiKey HOTP device is used for logging on the Mac, but the machine does not have an OATH seed stored on it or network connectivity, then the endpoint must wait for an available network connection.

If the end-user is attempting to log on for the first time, and the Mac does not have WiFi configured or is not using a wired connection, then the end-user will be locked out of logging on the Mac. Users Disabled in Active Directory If an end-user is disabled on Active Directory, the local account will not know the history of the AD account, and the user will not be able to log on the Mac. IMPORTANT: Before Installing Login for Mac Your local username and password on the Mac must be the same as your Active Directory username and password. If you are using a different local username than your Active Directory username, then you will need to contact IT to synchronize the IDs. If the IDs are synchronized, be sure you can log on the Mac before installing Login for Mac.

First-time Usage Requirements The first time you use Login for Mac to log on the network: A timed passcode is required. You must have an account provisioned with a SecureAuth IdP realm that enables your device to generate timed passcodes for Multi-Factor Authentication:., or. YubiKey HOTP Device – refer to the to ensure all requirements are met. Your Mac must either be hardwired to the network, or you must have a preconfigured WiFi connection within range to which your Mac can be manually connected.

Thereafter, you can use Login for Mac in the offline mode. On the Login for Endpoints Installer Configuration page, select Windows as the Endpoint Operating System. Select the Endpoint Type to specify that either a single user or multiple users can log on the device. NOTE: For the single user selection, once the user has successfully logged on the endpoint online, thereafter the user can log on the endpoint offline without an Internet connection.

Enter the IdP Hostname. Under Multi-Factor Authentication Settings, specify whether the user must use Multi-Factor Authentication to access the device from a desktop and / or remote desktop session. If any user group is allowed to bypass Multi-Factor Authentication, enable the bypass option and list the user group(s).

EXIF Viewer is a small Mac OS X application to display EXIF information in JPEG files coming from digital cameras. Simple EXIF Viewer for Mac OS X. This small application has only one function: displaying Exif information from digital pictures. It lacks any editing capability. This version fixes a small issue for SnowLeopard users. For Leopard users, it is recommended that they use 2.7 or older version of this program or they may run into compatibility issues. Microsoft edge exif viewer. EXIF Viewer is a small application which displays EXIF information in JPEG files coming from digital cameras. This version is based on Eric M. Johnston's 'exiftags' EXIF parsing code. Jan 05, 2015  EXIF Viewer is an unsophisticated Mac app that can be used to view the EXIF information that is embedded in JPG or THM files without too much trouble. The utility comes with a minimalist design and proves to be extremely easy to use.

Proxy Server and Proxy Bypass List Configuration If using a proxy bypass, you must configure the proxy server and proxy bypass list – i.e. A list of hosts to use to bypass the proxy. The following order is used: 1. 'proxyserver' and 'proxybypass' configuration from config.json file – these settings are derived from entries made in the Web Admin Login for Endpoints Installer Configuration section.

Windows proxy configuration – see 17. If enabling Password Reset, specify either the SecureAuth IdP realm or the web page URL the user can access for resetting a password. If Alternate Credential Providers are permitted, specify if non-SecureAuth credential providers and other credential providers such as card scanners can be used. IMPORTANT: By enabling alternate credential providers, users will be able log in without using the Login for Windows credential provider, and potentially bypass Multi-Factor Authentication. Enabling alternate credential providers is only recommended in test environments, to let testers bypass Login for Windows so they can readily access their machines. If the default Windows Credential Provider is enabled, users will see their normal login prompt and will have to manually select a different login option in order to use Login for Windows. Click Download Installer Config to download the JSON file (config.json) which must first be configured before it can be used with the MSI file, as described in the Installation section of this guide.

Secureauth Download For Windows 10

NOTE: Before installation, config.json must be edited if the end-user is not always required to use Multi-Factor Authentication for logging on a local console and / or remote console – see the OPTIONAL: Set End-user Access Level section for access level settings and configuration. A user group on another domain can be bypassed via the Mac authentication plugin and Pluggable Authentication Modules (PAM) installed on the end-user's workstation. In this scenario, the Open Directory API can be used by specifying the user group and domain.

Click Download Installer Config to download the JSON file (config.json ) that will be used with the PKG file, as described in the Installation section of this guide. NOTE: Before installation, the config.json file must be edited if the end-user is not always required to use Multi-Factor Authentication for logging on a local console and / or remote console – see the OPTIONAL: Set End-user Access Level section for access level settings and configuration. Also in this OPTIONAL section, find information about enabling Multi-Factor Authentication when using SSH for remote login access to a Mac. Login for Windows requires the end-user to use Multi-Factor Authentication by default to access the local console or remote console in an RDP session. Before installing Login for Windows on the end-user's (target) machine, the config.json file must be edited if you wish to change the end-user's login access level setting. Change the User's Access Level.

Find the config.json file which you downloaded in step 19 of the Web Admin Configuration section of this document, and copy that file to the Temp folder on the target machine. Start a text editor such as Notepad and edit the accesslevel in the file, changing the value to a pertinent value:. 0 = Multi-Factor Authentication always required. 1 = Multi-Factor Authentication required for local access only. 2 = Multi-Factor Authentication required for remote access only. 3 = Multi-Factor Authentication never required – this setting is used for Self-service Password Reset (SSPR) only 3.

Save the configuration. Login for Mac by default requires the end-user to use Multi-Factor Authentication to access the local console and a remote console in an SSH session. Before installing Login for Mac on the end-user's (target) machine, the config.json file must be edited if you wish to change the end-user's login access level setting. Change the User's Access Level. Find the config.json file which you downloaded in step 15 of the Web Admin Configuration section of this document, and copy that file to the Temp folder on the target machine. Start a text editor such as Sublime Text and edit the accesslevel in the file, changing the value to a pertinent value:.

0 = Multi-Factor Authentication always required. 1 = Multi-Factor Authentication required for local access only. 2 = Multi-Factor Authentication required for remote access only. 3 = Multi-Factor Authentication never required – this setting is used for Self-service Password Reset (SSPR) only 3. Save the configuration. Download and Run the Login for Windows MSI Package 1.

Download the.zip file to the target machine (laptop, desktop, server, etc.). Unzip the file. Within the Login for Windows folder, find the.msi file for your machine — SecureAuthLogin-1.x.x-x64.msi or SecureAuthLogin-1.x.x-x86.msi — and place that file in the Temp folder. Install Login for Windows IMPORTANT: On a Windows server, SecureAuth Login for Windows should only be installed / uninstalled from a console session and not an RDP session 1. Find the config.json file which you downloaded in step 19 of the Web Admin Configuration section of this document, and copy that file to the Temp folder on the target machine.

NOTE: You may have already performed this step if you changed the user's access level in the OPTIONAL section above. On the target machine, run the following command line with administrator permissions, using the file name of your.msi file and correct path of that file on your machine, as in this example: msiexec /i 'C: Temp SecureAuthLogin-1.0.0-x64.msi' /L.V 'C: Temp install.log' /qn CONFIG='C: Temp config.json' 3.

Log off the target machine. NOTE: After this installation, SecureAuth Login for Windows appears on the next login session. NOTE: A config.json file with the 'allowselfsigned' setting enabled should not be distributed to end-user machines since potential security vulnerabilities may result. The 'allowselfsigned' setting should only be enabled in a test environment, and should be disabled in conf.xml once testing is complete.

Verify TLS 1.1 and TLS 1.2 Enablement via GPO on Windows Server OS Verify TLS 1.1 and TLS 1.2 are enabled via the Group Policy Object (GPO) to ensure a streamlined and secure login experience for users logging on a Remote Desktop. NOTE: The external article ' ' provides instructions on how to enable TLS 1.1 and TLS 1.2. SecureAuth IdP Transaction Log Information The Login for Windows software issues a User-Agent HTTP Request Header when the Application Programming Interface interacts with SecureAuth IdP. The following items are included in the UserAgent string:. Login for Windows software version. OS version. Computer name (hostname).

Time Zone. IP address. MAC address For example: SecureAuthLogin for Windows 10.5.2 (Windows 10 Pro x64 6.2.9200; LT-JSMITH; (UTC-05:00) Eastern Standard Time; 111.22.333.44; 0f:10;35:7a:81:4e) Uninstallation 1.

On the target machine, run the following command line with administrator permissions, using the file name of your.msi file and correct path of that file on your machine: msiexec /x ' /L.V 'uninstall.log' /qn NOTE: Manual installation on Windows 10 using the 'Programs and Features' menu will result in an error. WARNING: Do not install Login for Mac version 1.0 on any MacOS Sierra machine (10.12.x) in a domain-joined system on which FileVault encryption is used on the boot volume – this may render the operating system unbootable and require recovery. Copy the JSON File to a Specified Folder 1. Find the config.json file which you downloaded in step 14 of the Web Admin Configuration section of this document. NOTE: You may have already performed this step if you changed the user's access level in the OPTIONAL section above.

Copy that file to a specified folder on the target machine. Download the Login for Mac ZIP File to the Specified Folder 1. Download the.zip file to the target machine. Unzip this file which contains the SecureAuthLogin-1.x.pkg and SecureAuthLogin-1.x-Uninstaller.pkg files. Copy these files to the same folder as the config.json file on the target machine.

Run the Login for Mac Installer Package 1. Double-click SecureAuthLogin-1.x.pkg to start the installation wizard for the application. Log Out of the target machine. NOTE: After this installation, SecureAuth Login for Mac appears on the next login session. On Windows 10 desktops, a Login Notification request cancelled on the desktop—but accepted on the SecureAuth Authenticate app on a mobile device—still gives the user login access on the machine. This issue has been raised with Microsoft, but at this time remains unaddressed by them. On Windows Server versions 2008 R2 and 2012 R2, users may be unable to complete the self-service password reset process due to default Internet Explorer settings in the operating systems.

If using a proxy which becomes unavailable, Login for Windows behaves as if it is offline. This issue may impact laptop users who connect their laptops to networks in which the proxy is unavailable. The Self-Service Password Reset feature – which opens a browser to a page – does not function in environments using a proxy to access SecureAuth IdP.

In these scenarios, contact and inquire about workarounds. Note this feature differs from the inline password reset feature that is used when a user’s password expires – this feature functions properly in proxy environments.

The Self-service Password Reset may not function correctly for certain operating systems. On Windows Server versions 2008 R2 and 2012 R2, users are unable to complete the self-service password reset process due to default Internet Explorer settings in the operating systems. Enter your username on the Windows login screen.

The first time you use Login for Windows, SecureAuth recommends selecting a timed passcode authentication option from the list of Multi-Factor Authentication methods for which you have enrolled. This could be one that uses the on your mobile device or another device provisioned with the SecureAuth IdP realm to supply timed passcodes, such as a. After selecting a timed authentication option and entering your password, the timed passcode option will be available for you to use when logging on this machine offline. If you do not have an authentication method that provides a timed passcode, then select any other option available to you. When using Login for Mac for the first time, you must supply a timed passcode from either the on your mobile device or another device provisioned with the SecureAuth IdP realm to supply timed passcodes, such as a YubiKey.

This window (pictured left) only appears the first time you use Login for Mac. Enter the passcode that appears on the device, and then click Submit. NOTE: After successfully logging on the Mac using a timed passcode, timed passcodes from that device can be used for login access in the offline mode, i.e. When the Mac is not connected to the Internet. Log Out of the Mac. Log back on the Mac, and select an authentication option from the list of Multi-Factor Authentication methods for which you have previously enrolled.

NOTE: If your list of available authentication options is lengthy, you may need to scroll down the list if the option you wish to choose does not appear on the main page. Optionally, check the Remember my selection box if you want to use this same authentication method the next time you log on the Mac. Click Submit to access the Mac on the network.

NOTE: Authentication method workflows are described in the sub-sections below. No matter which option you choose, you can return to this selection window by clicking the link: I want to choose a different two-factor authentication method. CP-187 RDP users utilizing NLA (Network Level Authentication) no longer receive a second prompt after providing credentials to the RDP client. CP-267 The Multi-Factor Authentication device order now remains consistent on subsequent login attempts.

CP-320 Login for Windows now remembers the most recently entered login username on a non-server. CP-340 An active hover link now appears when attempting to select another Multi-Factor Authentication method. CP-339 The correct HOTP icon now appears on passcode entry window. CP-379 Log details have been added to help troubleshoot common installation errors. CP-388 Users in offline mode now correctly receive Multi-Factor options that are usable offline. CP-393 Re-installing Login for Windows now applies configuration file updates.

CP-398 The installer error message for a missing configuration file has been revised for clarification. CP-400 First-time users must now use an OATH-based method (if enrolled in one) to ensure at least one OATH seed is cached for offline use. CP-403 The most recently used Multi-Factor Authentication device now appears when logging on / off Windows 7 or Windows 10. CP-408 SADiag.exe no longer returns an error when 'set logging off' and 'test api' log level settings are used. CP-410 The installer now accepts a relative path to the configuration file during a silent installation. CP-411 The correct username now appears on the lock screen on Windows 7 / Windows Server 2008. Known Issues.

CP-309 Login for Mac.pkg files have been renamed for consistency with Login for Windows.msi file names. CP-317 Login for Mac now validates the configuration file correctly. CP-327 The initial Multi-Factor Authentication method window now shows a selected option.

CP-359 The installation failure log (Command+L) now identifies a missing configuration file. CP-379 Log details have been added to help troubleshoot common installation errors. CP-398 The installer error message for a missing configuration file has been revised for clarification. CP-390 Users are no longer locked out on Sierra 10.12.x machines with a FileVault encrypted drive. CP-392 Device names receiving push requests now appear on Login for Mac waiting screens. Known Issues. Resolved Issues.

Incorrect IP addess used for Adaptive Authentication When logging on locally, SecureAuth IdP now correctly uses the endpoint's public-facing IP address instead of a local adaptor IP address. In this issue, a private IP address was being used which prevented IP-related Adaptive Authentication features from functioning properly. Remote / RDP logins were not impacted by this issue. AD bad password count incorrectly incremented When attempting to log on using a bad password, the bad password count now increments appropriately – i.e.

One time for each login attempt. In this issue, the Active Directory bad password count would increment multiple times for a single login attempt, causing the user to be locked out immediately or sooner than anticipated. In certain scenarios, the bad password count incremented once for each OATH seed-based Multi-Factor Authentication method – e.g. For each app-based OTP or hardware token. Re-installation breaks login functionality Login for Windows can now be re-installed on the same machine. In this issue, the Login for Windows software could become corrupted if re-installed on a machine which already had the software installed.

Secureauth Passcode For Microsoft Windows

This issue prevented users from logging in and required the user to boot up the machine in safe mode to repair the software. Non-proxy aware Beta support is now available for proxies in Login for Windows – see to configure Login for Windows 1.0.1 for use with a proxy. Note the known issues when using a proxy in the 1.0.1 release. This issue affected environments in which direct access to the SecureAuth IdP appliance is blocked and users must use a proxy. Login failure for users with a space in sAMAccountName The issue has been resolved for users who were unable to log in if a space exists in their sAMAccountName property. Users in a bypass group unable to use Self-Service Password Reset function The Self-Service Password Reset link now appears for users who are in a bypass group.

Known Issues. Installation requires an absolute path to the configuration file The installer does not accept a relative path to the configuration file, which prevents deploying the installer from a directory that cannot be defined in advance (such as when using a Group Policy). Potential offline lockout for new users To use the offline mode, a user must first use an OATH-based authentication method – such as a one-time code (OTP) generated by the – at least one time while online in order to cache the OATH seed used for authenticating the user. SecureAuth recommends instructing users how to enable the offline mode before they attempt to go online. A future release of Login for Windows will address the potential new user lockout issue by providing guidance to users during the login process. Double prompting for RDP logins Users utilizing NLA (Network Level Authentication) when logging on a system with RDP enabled may still be prompted for a username and password once the session is established.

Self-service Password Reset function is non-proxy aware The Self-service Password Reset feature – which opens a browser to a page – does not function in environments using a proxy to access SecureAuth IdP. In these scenarios, contact and inquire about workarounds. Note this feature differs from the inline password reset feature that is used when a user’s password expires – this feature functions properly in proxy environments. Self-service Password Reset may not function correctly for certain Operating Systems On Windows Server versions 2008 R2 and 2012 R2, users are unable to complete the self-service password reset process due to default Internet Explorer settings in the operating systems.

Offline endpoint when proxy is unavailable Use of any proxy configured for Login for Windows becomes mandatory. If the proxy is unavailable, Login for Windows behaves as if it is offline. This issue may impact laptop users who connect their laptops to networks in which the proxy is unavailable. Re-installing Login for Windows does not apply configuration file updates Re-running the installer with a new or updated configuration file does not result in configuration changes made to the current installation. Administrators must uninstall and then re-install Login for Windows to apply the new settings.

SMS and Voice numbers are not correctly masked Users prompted for Multi-Factor Authentication can view the full telephone number for a registered Multi-Factor Authentication method. Incorrect username shown on lock screen Users in a bypass group are shown the wrong username on a Windows 7 workstation lock screen. Known Issues. Login failure for users with a space in sAMAccountName The issue for users who are unable to log in if a space exists in their sAMAccountName property cannot be resolved because macOS does not support using spaces in login names. Critical issue with FileVault on Sierra Do not install Login for Mac 1.0 on MacOS 'Sierra' (10.12.x) in a domain-joined system that uses FileVault encryption on the boot volume; this may render the system unbootable and require recovery.

SMS and Voice numbers are not correctly masked Users prompted for Multi-Factor Authentication can view the full telephone number for a registered Multi-Factor Authentication method. Additional Authentication methods may be hidden Since many MacOS configurations do not display a scrollbar, users who are prompted to select an authentication method may not know there are additional methods available to them if they do not see them on the screen currently displayed.

Multi-Factor Authentication only prompts users at login Login for Mac does not currently support prompting users for additional factors when unlocking the screen of an already logged-in user. Offline login may not complete Users attempting to login offline for a second time using a TOTP code (after logging on and logging off) may have their machine after entering the code. Login for Mac will install on unsupported MacOS versions Login for Mac is only supported and tested on MacOS versions 10.12.x (Sierra) and 10.13.x (High Sierra), but currently the installer allows installation to proceed on versions 10.10.x and 10.11.x. Release Date: February 1, 2018.

I asked about this a year ago when 1Password didn't automate One-Time Passwords. Then, the issue was that when I would supply the second factor (either a code delivered to my iOS device via the 'SecureAuth' iOS app, or a code that appeared in rotation on my RSA key fob) 1Password would ask me to save the changes to my login credentials, which of course were not permanent. You told me how to prevent that. Now, the issue is the obverse.

1Password now supports at least some 2-factor authentication methods, but I don't believe that I can shoehorn what I must do into the capabilities of 1Password 6. These are both very large enterprise healthcare sites (with large IT teams endowed with HIPAA paranoia in their DNA, of course). Perhaps we should be discussing this in a private conversation so that if there is a potential automation solution within 1Password, I could identify the enterprises for you to help you determine whether it is possible to ditch the key fob for one site and/or leave my phone in my pocket for the other. When I set up my login credentials for these sites with the help of their tech support personnel, I was assigned a serialized RSA token for one site, and provided a 'registration code' and server address for using the SecureAuth iOS app for the other. Enabling 2-factor authentication didn't involve using a QR code to register my interface for receiving the second factor at either site. Can 1Password be configured to be the receiver for the second factor for either of these sites?

Thanks so much 1Password Version: 6.0.1 Mac Extension Version: 4.5.2 OS Version: OS X 10.11.3 Sync Type: DropBox Referrer: ug:, ug:, kb-search. Hi, Currently 1Password currently only supports Time-Based-One-Time-Passwords as a 2nd-factor. Unfortunately it can't be configured to be a SecureAuth IdP client to have the SecureAuth One-Time-Passwords sent to it, so that's going to rule that one out. From what I gather, SecureAuth works by having the website you're logging into send them (SecureAuth) the 8 digit code. SecureAuth then sends it to you via their app.

So there's a middle man there, SecureAuth. I don't realistically see us being able to add support for this. Time-Based-One-Time-Passwords are simpler and work without a middle-man, which is why we're able to support it. It works by giving you a secret (typically encoded somewhere in the QR code or a URL). You feed that secret into an app like 1Password, and now both 1Password and the server have this secret. When you login the server uses its secret and the current time to determine what the correct one time password is.

Secureauth Authenticate App

On our end we do the same calculation, and we should arrive at the same result. Same kind of principle, but no middle-man. We don't support RSA, though it works more like Time-Based-One-Time-Passwords. I know that we'd like to expand our support for OTP to support different kinds, but I'm not sure if RSA is on that list. I hope this helps. I think the reason RSA tokens are still around is what I said in my last message.

For most of us in the US (or Canada ) a glass door with a simple tumbler lock that provides access to the swimming pool on the patio is secure enough. For most health care workers seeking remote access to their EHR from Starbucks, it' s unlikely someone from the NSA (or its targets) is sitting at the next table trying to sniff their laptop, so the numbers on the RSA key fob really DO add to the security of remembered or written-down User ID/PW combinations. Hi CalfeeRider, FYI, In a former job (15+ years ago), it was my responsibility to test RSA SecureAuth token integration into optical networking switches.

They were an effective method, though did have their share of issues too, and I believe some generations of them have been compromised. As Rick mentioned, there is a fair amount of work to do this, and I'm not sure if it's a suitable fit at this time, but it is an interesting authentication technology, for sure, and we do follow as many as we can to see what is suitable for 1Password. Thanks for taking the time to write in! Cheers, Kevin.