5.500 apps potentially vulnerable to Man in the Middle attacks in Google Play

Monday, December 22, 2014

It has been discovered than AppsGeyser, an app creator "with just a few clicks", deactivates the SSL certificate validation in its apps. An attacker on the same network as the user running these apps, will be able to inject any page when browsing from the affected apps, or view and modify webs that should be protected. This app generator is very popular and (as they show in their own web, there have been installed almost a thousand million apps). There are 5500 AppsGeyser apps in this moment in Google Play. Let's analyze the problem, and its details.

AppsGeyser main website

AppsGeyseris a service that eases the creation of Android apps with just a few clicks. Literally, it allows users to create apps in three simple steps, so the web experience is translated to an app. This kind of applications introduce risks we have already talked about, since de programmer does not control the code and it may introduce unwanted security vulnerabilities.

In this case, AppsGeyser has deliberately introduced a function that disables the SSL certificate validation of HTTPS traffic in all apps developed from this platform. This vulnerability means that any navigation from an app created by AppsGeyser may be intercepted, forwarded, faked... No certificate from the remote server will be validated.

In order to be successful, the attacker has to be on the same local network as the victim. Then the attacker needs to access the victim’s traffic with any known technique (ARP spoofing, proxy control, gateway...) and analyze the traffic generated from any of the apps created with AppsGeyser. If an user of these apps visits an HTTPS website, the attacker would just have to introduce his own web signed with any certificate, and the victim would not notice anything. It would be like the perfect phishing. Or intercepting traffic between the victim and a secure website. Even if the victim does not explicitly visits an HTTPS webpage, the attacker could redirect him. For example, if an AppsGeyser apps visits some ads, the attacker could forward the user to a fake Facebook, Twitter, etc. webpage and ask for his password in any moment. 

5.500 vulnerable apps

By using Path5, ElevenPaths’s app markets monitorization, correlation and research product, we have been able to detect 5.532 AppsGeyser apps created and still active on Google Play. During this year, more than 7.000 have been in this official platform, what confirms its popularity. There is even a browser developed with AppsGeyser that claims to be a tool to easily visit Twitter, Amazon, Facebook... in a totally insecure way. Some antivirus already detected AppsGeyser apps as badware, no matter the app’s features.. Now it is confirmed that they have good reasons to do it. 

A browser with direct links to popular pages, created with AppsGeyser

There are some serious institutions and companies that have used this method to create its app. Even very popular apps with hundreds of thousands of downloads. There are about 50 apps created with this platform that have been downloaded more than 100.000 times.

Maybe not every single one of them is vulnerable, but we have our doubts. In order to avoid being vulnerable, the original developer should have to add or remove the SSL explicit deactivation made by AppsGeyser. The vast majority of developers that have delegated the development of an app to a third party, it is not very likely they have the needed technical level for solving it. Moreover, AppsGeyser does not tell the developer that is invalidating the SSL check. 

Why deactivating SSL? We think that is has been done to make everything easier for the creator using autosigned certificates for his web, or certificates that can not be validated by the system. AppsGeyser saves support incidents in its support system. Users will never see a "SSL validation error" with their apps. AppsGeyser disables SSL certificate validation and then they avoid problems to their support department, but jeopardizes any user of their apps.

Proof of concept

This proof of concept shows a MITM attack against an AppsGeyser app (https://play.google.com/store/apps/details?id=com.SantiniLabsWebBrowser) that allows to get encrypted traffic. The attacker has to enable IP forwarding and redirect HTTP AND HTTPS traffic to a webproxy in this machine.

Then he needs to launch an ARP spoofing attack (although any other technique would work).

The victim opens a Facebook session from the browser in the app.

The traffic is captured, although the user thinks is encrypted, since actually all is done with the non-trusted certificate in the webproxy:

The user would not be able to check the certificate from the browser, because the app does not allow this functionality.

Technical details

Technically, the failure is easy to spot. For example, we can have a look to the code from this browser created with AppsGeyser. It would be the same in any app created with this third party that have not explicitly fixed the vulnerability.

In the onCreate(…) method in the initial activity, we can find the following code snippet:

The first highlighted line, stores in the mStartupScreenViewContainer attribute the FrameLayout startupScreenContainer , that we will see when the app is launched. The second line, creates a controller from the FrameLayout with this code:

StartupScreenController class contains these attributes:

BrowserWebView will be the one in charge of showing web pages. To get it, it will need to use a WebViewClient object, established when building StartupScreenController:

You can see highlighted in this code, how BrowserWebView is recovered (in the initial activity layout) and how the WebViewClient is assigned as an instance of FullScreenBannerWebViewClient object.

As we can see, the class inherits from SimpleWebViewClient:

That in turn, inherits from WebViewClient, that, according to the Android API documentation, has the following method:

And this method is overwritten in SimpleWebViewClient with the following code, so, when an invalid SSL certificate is found, the page is still loaded with no warnings.

So, risky connections inside the apps, would be the ones from the objects that inherit from SimpleWebViewClient and BrowserWebViewClient. and provided that they do not overwrite onReceivedSslError behavior with paramSslErrorHandler.cancel().

Miguel Ángel García

Sergio de los Santos

Latch USB Monitor: New tool to monitor PNP devices with Latch

Thursday, December 11, 2014

Latch USB Monitor is a tool that monitors Plug 'n Play device (PNP) changes in Windows and gives the user the possibility of tracking incoming devices, and react accordingly to a preconfigured Latch response. For instance, it would allow to block USB ports so it will not recognize a new inserted memory USB stick until it is authorized with the movile device.

This means that Latch USB Monitor will ask Latch servers what to do when a certain PNP device is detected in a Windows machine. So the administrator has a tool to potentially react to plugged devices, and modify the behavior and scripts launched in any way, at any moment, just sliding a bar from his mobile device.

How it works

Latch USB Monitor works as a service and has a GUI to configure it. That means it still works and monitors incoming devices even when no user is logged in. The service is constantly monitoring any device with the characteristics given by the user. When it occurs, it asks Latch servers and reacts in the way that the user has configured it.

It may as well be used as an alerting system, with no action associated to an event. So if a device is plugged to the machine, a blocking message is sent by Latch to the mobile device, but no action is taken.

Latch USB Monitor with some configured rules

 How to install it

No special instructions. Just accept the license and choose the path. If, for the sake of security, you do not want the service to run as SYSTEM, you may change it to whatever account you wish, as long as it has privileges to run as a service, and network access.

A config file is created in XML format. This file contains sensitive information. Take care with the permissions specially in shared computers.

Pairing with Latch

First of all, a Latch account has to be set with a pairing token. Go to Latch management and add the App ID and secret. A timeout is specified here. This means that if the computer is not connected to a network or, for any other reason it cannot get a response from Latch in the specified time limit (0 milliseconds by default which corresponds to no timeout) the "no response" action is applied.

How to add and configure a device

Each monitored device, may have these fields:
  • Device (optional): If your device is currently plugged in, you can choose it from this dropdown menu where all attached devices are listed.
  • Description (optional): Giving a meaningful description of the device helps you better identify it in the main list.
  • Device Instance ID: The ID that uniquely identifies a device in a Windows machine. When an arriving Device Instance ID is detected it goes through a matching system that can be used to discard or allow the rule. If the string set matches, the Latch query will be launched. This is treated as a string, so "Starts with", "Contains"... may be used to match.
  • Operation ID: The operation ID used in Latch.
  • Actions.Open (optional): If the Latch query responds with an "on", the process specified here will be launched, with the specified argument set (optional).
  • Actions.Closed (optional): If the Latch query responds with an "off", the process specified here will be launched, with the specified argument set (optional).
  • Actions.No response (optional): If the Latch query doesn't respond (because there's no connectivity, for instance, after the timeout declared in "Latch settings"), the process specified here will be launched, with the specified argument set (optional).

    Device details with pendrive example

    The tool is written in C# and may be freely downloaded from: https://elevenpaths.com/downloads/LatchUSBMonitor.zip. You may want to check out Latch Event Monitor, too.

    We encourage you to use it.

    PhpMyAdmin fixes a XSS detected by ElevenPaths (CVE-2014-9219)

    Thursday, December 4, 2014

    On November 28th, while our Faast team was developing an intrusion module for PhpMyAdmin MySQL manager, we detected a new cross site scripting vulnerability not known so far in this popular program. It has been privately reported to the team responsible for PhpMyAdmin security and the CVE-2014-9219 has been assigned. It affected all known versions.

    Vulnerability and fix announce

    PhpMyAdmin security team has reacted promptly and in just three days they have fixed the problem and released a new version. The vulnerability (currently exploitable in any version previous to relies in a bad filtering in the "url.php" file. The function htmlspecialchars was being incorrectly used.

    The figure below shows the applied patch where htmlspecialchars function is replaced by PMA_escapeJsString.

    Commit 9b2479b7216dd91a6cc2f231c0fd6b85d457f6e2 with the fixing line

    Just filtering HTML special characters, its exploitation was trivial. Besides, it was possible to bypass anti-XSS protections in browsers, because the injected code was reflexed into a "script" tag. This kind of vulnerabilities are very common in web applications, and allow different attacks, as obtaining session cookies, as shown in the figure below.

    Exploiting the vulnerability

    If you are using PhpMyAdmin, it is recommended to update as soon as possible to latest version ( or applying the patch available here. Besides, we recommend using Faast that, of course, already detects this vulnerability.

    Finally, remember we have a Latch plugin for PhpMyAdmin. All the information about how to install it, is here.

    Manuel Fernández

    Shuabang botnet: BlackHat App Store Optimization (BlackASO) in Google Play

    Tuesday, November 25, 2014

    ElevenPaths has detected malicious apps in Google Play (already removed by Google), aimed at performing Shuabang techniques, or BlackASO (Black Hat App Store Optimization). These malicious apps link fake accounts with the real device of the victim, getting very "real" accounts. With these accounts, the attacker sends tasks to the victims so they download apps (although not effective on the victim's device). The victim's account remains safe, but not the data about the phone. We describe in this report the details of this interesting attack.


    Shuabang techniques, or BlackASO (Black Hat App Store Optimization). This is a real industry in China that has been active for years. The method consists in creating an infrastructure to score or artificially inflate the number of downloads of an app so they rise up their position on the markets. This infrastructure requires fundamentally Google or iOS accounts so they can distort actions, as if they were generated by real users. This "service" is usually sold to a third party intermediary (companies) that claim to enhance and optimize positions in any market but they do not really care about the methods to achieve it.

    To carry out the fraudulent scheme, the attacker needs active Google accounts associated with real devices that do not appear suspicious to Google, which would quickly eliminate them otherwise. Different techniques are used for this purpose. The most usual is to manually hire users that will create accounts in the market and rate apps they are told to. On this particular occasion, they came up with a system that starting from a set of fake Google accounts, distributes and associates them to different devices, so they take full advantage of the number of phones associated with an account. Besides, it allows sending tasks to the device so it simulates downloading apps under fake accounts. The potential of these malicious apps spotted for Shuabang is above average, since it demonstrates in-depth knowledge of the specific operation of Google's authentication protocols. Before getting into the details, let's see how Google accounts work.

    How Google accounts work

    When a user creates a Google account, once the username and password are provided, he has access to dozens of Google services, as a Single Sign On.

    Google account working schema

    The user enters the account password in the device only once. From that point on, he is registered in a Google service (for example Google Play, sending user, password, device ID...) that will return a token. This master token is stored in the device account manager (that remains associated) and will be used from then on in the device  (that remains associated to it) so the password does not have to be entered again. Other temporary tokens are derived from this master token. It is common for users to have several devices registered with the same account. This, for example, allows users to choose where to install apps. For linking or associating a device to an account, the usual process is:

    Registering and associating and account with a device

      • Either creating the account from the device itself. Google prevents automatic creation of fraudulent accounts by discarding accounts created on devices that are not "real", as well as inserting a CAPTCHA.
      • Or using an existing Google account and signing in with it on the device that it is to be associated with. This process only requires entering the username and password in the phone to add a new account.
      What Google does, is associating a device identifier with the account. The Android phone or device will appear as a device associated with the account on the Google Play settings panel.

      This low-level registration and association protocol has been studied by the community and specially by attackers who carry out fraudulent practices. Registration and association can currently be programmed with raw calls to Google services and providing the necessary information. This process isn't officially documented, though.

      This kind of botnet is a sophisticated system by which attackers use apps with minimum privileges to associate accounts created by them to real devices. Thus, attackers obtain a number of fake accounts associated with "real" phones and therefore valid for Google services, allowing them to carry out a variety of fraudulent schemes. Specifically, artificially increase app downloads or fraudulent app rating.

      The attack

      The attacker had a pool of 12.500 Google accounts, created with valid username and passwords, but not registered with any device. The vast majority of accounts in this database were created by the attacker, and were delivered to the victims to register them with their devices.

      Brief attack scheme

      Fundamentally, the attacker gets the victim to make two actions:
      • Associate accounts to devices in an automatic way so he can get tokens.
      • Use these tokens in a distributed way, so downloads may be simulated.

      Real example of a response to an infected device, getting an account that will be associated to the device

      The applications turn the device into a zombie that collected these fake accounts from the central server every 10 minutes and associated them with the information on the victim's phone. The "original" Google account on the victim's device remains safe and the attacker cannot access it at any time. Each account was associated with between 10 and 30 physical phones of victims. The combinations between Google accounts and associated phones are countless. The image shows an example of an attacker account associated with 18 victim devices.

      Example of an account associated with different victims' devices

      The attacker published more than 300 applications on Google Play throughout the month of October. They were disguised as games, jokes, wallpapers and general entertainment. Of these, approximately 100 committed the fraud by associating these fake accounts to the device's settings and identifier. The remaining 200, although harmless in their first version, were usually later updated to commit the fraud. The permissions the apps requested are:

      Permissions requested by the apps infecting the users

      With this attack scheme, the attacker has obtained a database of  60,000 tokens. The attack was focused on victims in Brazil, India and Russia, although it was prepared to add any other country.

      The complete attack scheme is this:

      General scheme of the attack


      Although the attacker seems to have a known ultimate goal (black ASO), he achieved several interesting milestones by developing these malicious apps:
      • He created or bought 12,567 Google accounts, most of which were automatically created. Account creation requires breaking a CAPTCHA.
      • He achieved a low level understanding of the Google registration and device to account association process. He was able to program them to work automatically. This is not officially documented and there is very little documentation about this.
      • He was able to introduce some 100 malicious apps in Google Play with apparently harmless permissions.
      • He was able to manage a task system that fully optimized the activity of the infected network by distributing download and account association tasks, etc.
      • He was able to use the victims' devices features to associate them with accounts and thus perpetrate the fraud, as if a fake user was registered in the victim's device.
      • Although the victim's account data is not affected, these malicious apps imply taking advantage of resources and violating privacy.

      Although the Shuabang technique has been known and developed for some time via a variety of apps, the attackers' target is usually Google Play as an area for privileged distribution. This is the market that poses the most problems for publishing, but once they get it, and thanks to this intelligent technique described, the success for the attacker is remarkable. These malicious apps seem to be in a development phase, and it seems they were experimenting with these techniques.

      A complete report in PDF format is available from here.

      ElevenPaths has been able to determine how, since when and by which methods the fraud was committed and also established links between this attacker and other groups of attackers aside from gathering a series of incriminating evidence. Based on these correlations, ElevenPaths was able to find Google Play developer accounts possibly belonging to the same group of attackers.

      All of which was possible thanks to the use of Path5, a product developed by ElevenPaths, which allows early detection, investigation and correlation of any type of information about Android applications, among other functionalities.This report is a real-life example of the power and effectiveness of a product such as Path5 to investigate similar cases.

      Sergio de los Santos

      News: Latch plugin for SugarCRM is out

      Wednesday, August 27, 2014

      We have uploaded to GitHub our latest plugin for SugarCRM. It makes it easier to use Latch technology with this popular CRM platform. You can download it form here. This is a little "how to" so you can check how easy the integration is.


      Admins have to follow the usual steps if they want to protect SugarCRM with Latch:

      1. Create a developer account if they haven´t it.
      2. Create an application with the features they want.
      3. Download the plugin.
      4. Install and configure the plugin in their SugarCRM environment. 
      Steps 1, 2 and 3 are documented on the website of Eleven Paths, step 4 is going to explained in this post.

      Go to the "Admin" panel in SugarCRM.

      SugarCRM Admin Panel

      Go to module loader using the "Module Loader" link, in the "Developer Tools" section.

      "Module Loader" in SugarCRM

      In this section add the downloaded zip file, upload and install it.

      Add the downloaded module to SugarCRM

      Module installation

      Next, rebuild SugarCRM template. Return to the "Admin" panel and click on the "Repair" link, and then on "Quick Repair and Rebuild".

      Rebuild the templates

      Once the process is completed, SugarCRM will rebuild the application and Latch module can now be set up. A "Latch Configuration" link will appear in the "Admin" panel.

      Accessing Latch module setup menu

      Here the administrator has to add the Application ID and the Application Secret.

      Application ID an Application secret form

      Latch is now ready to be used and users are ready to pair their accounts. Users with SugarCRM accounts have to set their own accounts going to "Pair with Latch" and typing the characters generated with the phone into the text box displayed on the web. Once the token generated by Latch is introduced into their accounts, a notification will be received on the phone, announcing that the account is already paired.

      SugarCRM successfully paired

      Now the user may lock and unlock access to his SugarCRM account and a notification on his phone will be received, warning about anyone trying to access the account.

      Notification of an unauthorized access attempt

      The database

      When the plugin is installed in SugarCRM, SugarCRM database is set to store the values needed by Latch.
      The latch_accounts table indicates which user account has been paired with Latch, and the account id user.

      Table latch_accounts with the users that have already paired their accounts

      News: Latch plugin for Moodle is out

      Friday, August 15, 2014

      We have uploaded to GitHub our latest plugin for Moodle. It makes it easier to use Latch technology with this popular e-learning platform. You can download it form here. This is a little "how to" so you can check how easy the integration is.


      Admins have to follow the usual steps if they want to protect Moddle with Latch:

      1. Create a developer account if they haven´t it.
      2. Create an application with the features they want (one-time password has not been implemented yet for Moodle).
      3. Download the plugin.
      4. Install and configure the plugin in their Moodle environment.

      Steps 1, 2 and 3 are documented on the website of Eleven Paths and step 4 is going to explained in this post.

      Moodle plugin is a zip file, copy its contents to the root directory of Moodle.

      Moodle root directory

      After copying the plugin, Moodle administrator has to access his own account with username and password, and complete the installation.

      Confirmation message

      To set up the plugin, the administrator should go to the "Manage authentication" section, under the "Site administration - Plugins - Authentication" menu and enable the Latch plugin.

      Enabling the plugin

      After enabling the plugin, the administrator has to enter the "Application ID" and the "Secret" to the section corresponding to "Latch" under the "Site administration - Plugins - Authentication" menu.

      Entering the app ID and the Secret

      Latch is now ready to be used and users are ready to pair their acounts. Users with Moodle accounts have to set their own accounts going to "My Profile settings – Edit profile", access the "Latch" section. Type the token generated on the phone into the text box displayed on the web.

      Introduce the token generated by Latch app

      A notification will be received on the phone, announcing that the account is already paired.

      Notification after successful pairing
      Now the user may lock and unlock access to his Moodle account and a notification on his phone will be received, warning about somebody trying to access the account

      Notification of an unauthorized access attemp

      The database

      When Latch is installed in Moodle, Moodle database is set to store the values needed by Latch. Specifically the mdl_config_plugins table stores the Application ID and App Secret.

      mdl_config_plugin table with the Application ID an the Secret

      The mdl_user_info_data table indicates which user account has been paired with Latch.

      mdl_user_info_data table with the users that have already paired their accounts

      Latch in Node.js... too mainstream?

      Thursday, July 17, 2014

      Hoy en día cuando comenzamos cualquier proyecto web que se precie existen unos pasos de obligado cumplimiento si queremos estar en la cresta de la ola y convertirnos en verdaderos "hipsters". Lejos quedaron las épocas donde se usaban frameworks que eran "mainstream", donde los hombres eran hombres (y las mujeres mujeres) y escribían sus propios drivers.
      Node.js? Too mainstream

      Actualmente estamos viviendo una carrera continua para ser más modernos: desde frameworks como Nodyn donde desarrollamos en ClojureScript que compila a JavaScript, se ejecuta en Node.js que compila a una... ¡JVM!, a infinidad de variedades de AngularJS (EmberJS, Backbone, Knockout, Ractive.js etc.), alternativas a Grunt como gulp.js, alternativas a Yeoman como FireShell, pasando por convertidores de JavaScript a CoffeeScript, o mejoras sobre el propio CoffeeScript como Six o Functional Reactive Programming como bacon.js.

      Básicamente, estos son los pasos principales para desarrollar cualquier proyecto web en 2014:
      1. Escribe tweets sobre él.
      2. Fotografía tu espacio de trabajo y súbelo a Instagram.
      3. Elige tu framework JS.
      4. Configura tu MongoDB y Redis.
      5. Visita Reddit, meneame, forocoches y similares.
      6. ...
      7. Profit
      Bromas aparte, es para nosotros un placer tener ya disponible un SDK de Latch para Node.js e incluso una estrategia de autenticación para PassportJS de Latch. Para los que no lo conozcan, Node.js es un framework creado en 2009 por Ryan Dahl y su desarrollo está patrocinado por la empresa Joyent (compañía que ofrece IaaS y PaaS, y entre cuyos inversores se encuentra Telefónica).

      Su característica principal es que está basado en el famoso y potente motor V8 de JavaScript de Google y pretende ofrecer una forma fácil y segura de crear aplicaciones en JavaScript escalables y de altas prestaciones. De hecho una de las características que cuesta un poco al principio entender es su orientación mayoritaria a utilizar código asíncrono y basado en eventos, que puede llegar a ser más complejo que uno síncrono normal.

      Si se comprueba el código del SDK de Latch veremos que, realmente, es muy sencillo (el código siguiente está extraído de index.js).

      Primero tenemos que añadir las cabeceras HTTP que necesitan recibir nuestros servidores de Latch para saber que las peticiones son correctas:
      Y luego simplemente hacemos la petición HTTP a nuestros servidores de Latch con la operación escogida.

      Observando este último código podemos ver una parte de funcionamiento de Node.js donde se aprecia ese carácter asíncrono que se ha mencionado. La petición HTTP que realizamos (el "request") es a su vez una función donde podemos ver varios eventos; en la respuesta tenemos el evento "data", que significa que estamos recibiendo datos, y también el evento "end" que significa que ya hemos recibido todos los datos y pueden ser tratados si se quiere (o se podrían haber tratado según llegaban). También existe un evento "error" en la petición, en el caso de que hubiera algún problema con la petición HTTP.

      Así de sencillo; con unas cuantas líneas tenemos implementado todo el SDK de Latch en Node.js. También hemos puesto a disposición de todos una estrategia de autenticación de PassportJS para que sea fácil su uso: Ahí mostramos ejemplos de cómo utilizar Latch, ya sea como:
      En definitiva, el SDK de latch para Node.js se une a lista de SDK existentes como PHP, Java, Ruby, Python, C, .NET o PowerShell para que se puedan utilizar en todas las aplicaciones.

      David Barroso

      News: Latch plugin for Windows is out

      Wednesday, July 9, 2014

      With this plugin, you may protect access to Windows Systems, as a standalone machine not connected to any other authenticator. The plugin may be downloaded directly from here or here depending on your architecture. This personal edition is for free, but it is necessary to register to get a developer account with an AppiD and Secret if you do not have one yet. Visit https://latch.elevenpaths.com and, on the upper right side, click on "Developer's area".

      Here is a little how to so you can check how easy the integration is. The only prerequisites you need is Microsoft Windows version XP SP 3 or later. For a professional version of this plugin, valid for Active Directory, please check the Enterprise version here.

      Installing and configuring

      Unzip the program and execute latch_windows_plugin_pe_64.exe. By default, the plugin is added as a standard program under "Eleven Paths" folder, "Latch for Windows". Usually this will be: "C:\Program Files (x86)\Eleven Paths\Latch for Windows\" or "C:\Program Files\Eleven Paths\Latch for Windows\" depending on the architecture. Check the “Enable” checkbox and click "Latch Settings".

      Click on "Enabled" to start using Latch for Windows

      • Complete the fields with the Application ID and Secret previously generated in developer's area, and click "OK" . Operation ID is not mandatory.

      In "Latch settings", fill the fields up with Application Id and Secret key

      • Back to the main window, click on "Add" and add an username. From the Latch app on the phone, generate the token and complete the "Pairing token" box in "User options" window, and click the button "Pair" and "OK".

      Add an username and generate a token with your app

      Generate a pairing token for the user

      • The user is added to the list. Restart Windows, and the plugin is now ready to be used.

       Using Latch 

      From now on, the user may lock his Windows account in his smartphone so no one will be able to log in even if the password is known.

      Lock or unlock the account from Latch app

      Even if the password is correct, the user will not be able to log in until the latch is unlocked