MOGO+ uses different types of encryption techniques to make it one of the world’s most secure password keeping apps.
- Triple DES encryption with 3 key technology
- SHA and 1024 bit RSA public encryption for internal security purposes. MOGO+ also uses 128 bit SSL for all communications.
Some of the features and benefits of the MOGO+ Distributed Security Architecture (DSA) are listed below.
MOGO+ has no centralised storage of usernames and passwords
The critical focus in designing a secure system is to minimise the risk that the system is a target in the first place. If there is nothing to be gained by compromising the system, it is far less likely to become a target than a system that contains all the usernames and passwords for users’ accounts with financial service institutions.
MOGO+ has no centralised place where usernames and passwords are held. These are held encrypted on each individual user’s machine, with only the decryption key held on the server.
Client Side Data Aggregation vs Server Side Data Aggregation
A third party server based aggregation solution holds all usernames and passwords on the server. Most account aggregation solutions are implemented in a way that effectively allows a user to access all their accounts with a single username/password.
The reason multiple passwords are more secure than single passwords is because if something were compromised, a user could cut their losses on the one account as opposed to losing everything. This makes server based solutions extremely insecure.
If a user’s single aggregation password is compromised, then that user can lose everything. In the DSA application there is also a single password, however if compromised an unauthorized user still can’t access the individual accounts since the usernames and passwords are only on that user’s device.
The unauthorized person would also need full access to the user’s device. This inherently makes DSA far more secure than any host based solution. In the DSA application there is a separation of encrypted data and the decryption key. The encrypted data is on the user’s Device, while the key to decrypt the data is on the DSA server. If a user’s Device is compromised, it will not be possible to locate the key on the device because it is not stored there. On the other hand, if the DSA server were compromised, no usernames, passwords or data would be compromised since they are not stored on the server.
A significant issue with third party aggregation solutions is that they need to hold both the encrypted usernames and passwords and the key to decrypt them on their system. If someone compromises their system, then they could have access to both the encrypted data and the key to decrypt it.
MOGO+ separates encrypted data and decryption key
MOGO+ uses bank-standard hashing of passwords and separation of encrypted data and keys
Most financial institutions do not store users passwords in their system in any form that can be decrypted into plain text. Institutions do not use a reversible encryption mechanism, they run the password through a one-way hashing algorithm and store the hashed password. When a user logs in, they run the users login password through the algorithm and then compare the hashed passwords to verify the password. This is why if a user loses the password or pin, most financial institutions cannot tell you what your password or pin is – they have to reissue you a new pin.
This is a secure practice as not even the institution’s employees are able to gain a user’s password. The nature of third party host based aggregator architecture dictates that they have to store the passwords in an encrypted form that can be decrypted. This is a fundamental architectural security flaw. This means that the third party server based solution has both pieces i.e. the encrypted usernames, passwords and the key to decrypt them and needs to bring them together on the server to perform aggregation. Anyone (even a disgruntled employee) who compromises a server based solution, therefore could have access to everything required to transact on users’ accounts.
The MOGO+ DSA does not have this issue, since the user’s Device has the encrypted usernames and password – and the DSA servers have the keys with no actual usernames and passwords on the system.
Server password issues
There is a potential problem in third party server solutions relating to the automated scraping of data from users’ accounts at least once a day. The problem occurs if a user changes their login password to any of their online accounts. In the server models the server may try with the old details and get rejected.
If the server tries 3 times a day, they could lock the account since many institutions lock out accounts after 3 failed login attempts. The user could get locked out without even realizing what caused it.
With MOGO’s DSA, the control is directly in the user’s hands and the user initiates all logins and can monitor the login process.
DSA never overloads institutions’ systems
A significant issue with periodic scraping from third party host based solutions is that they have to scrape the details of every one of their users from every institution multiple times a day, on the off chance that the user may log in to the aggregation site.
Even if the user does then log in to the aggregation site they are most likely to update the details at the time they are logged in since the details they are presented with are out of date. The more users the host based aggregators acquire the more of a problem this becomes for them in terms of hardware and bandwidth requirements but even more important is the extra burden they are placing on the institutions they scrape. If for example they have 50,000 customers with a particular bank selected as an institution, it means that they will scrape the bank’s site at least once a day by logging in on behalf of every user simultaneously and scraping the data.
That places a tremendous load on the bank’s IT infrastructure and has been likened by institutions to a “denial of service” attack. In addition, most institutions perform backups and maintenance in the evenings, which is usually when the third party aggregators hit their site. The more successful the aggregation service is, in terms of numbers of users using the service, the more of a problem this becomes. This is a major limiting factor on the scalability of third party aggregators.
Additionally, if the user numbers get very large and the institution has a slow site, the aggregator may not even be able to scrape all their customers’ data over a 24-hour period.
This makes the data the user is presented with even more out of date and necessitating another update. The DSA architecture initiates the “harvesting” from each individual user’s Device – only when required by the user. Each “harvesting” action is indistinguishable from the user logging in directly.
MOGO+ is therefore much more institution friendly and scalable, as it does not place an extra unnecessary burden on the institutions’ servers.
Blocking of aggregation services is avoided by MOGO+
Any institution which is unhappy with a third party aggregator scraping data from their site (e.g. concerns of security, privacy, copyright or extra burden on their servers) can block the IP address of the third party aggregator, making its systems inaccessible to the aggregator. This has already happened with a third party aggregator and a major bank in Australia.
With MOGO+ the DSA solution each user performs the “harvesting” from their individual IP address – there is no central IP address that can be blocked.
MOGO+ avoids the problem of backups and deregistration in the server model
Most of the third party server models have very tight security in their data centers. If a center is damaged, they would need to restore data from backups. As the backups are stored offsite, this creates yet another possible point from which the user’s logins can be stolen.
Where a user decides to deregister from a service provided by a third party, all the usernames and passwords would have been backed up onto various media. When the user deregisters, if the server model were to be secure, they would have to go through all old backups and purge that user’s data off the system. It is almost impossible for this to be done.
This means that anyone who uses the third party server based aggregation at any time will have their details on the server backups for a long (if not permanent) period of time. How can a user ever be sure that the user’s details are removed? Any security concerns a user has will impact on their decision to use the system.
In the DSA model, the servers and backups do not have the same problem since the stored data does not contain usernames or passwords.
MOGO+ completely avoids the backup security problem.