Category: Tech Support – General

We don’t talk much about security issues at our website for obvious reasons – any information we provide could inform a hacker and provide them a shortcut to circumventing security on our site. We’ve recently made some changes that we want you to be aware of for a couple of reasons: First, the changes are comprehensive and as a result, could affect you in ways we haven’t anticipated. Second, we want to reassure you that your information is and always has been secure.

Let’s take that last point first: Laridian doesn’t store your PayPal username or password, nor do we store your credit card number on our servers. When you make a payment, you are interacting directly with either PayPal or our payment processor, Authorize.Net. Your financial information does not even pass through our server on its way to those companies. So we have no opportunity to store it even if we wanted to.

This is important. It means that your financial information isn’t here, even if someone did break in looking for it. It is being handled by companies that are significantly more sophisticated and more security-conscious than we are. The data breaches you read about don’t generally happen at banks and credit card processors. They are almost always the result of a retail store or online shopping site with lax security. Laridian avoids these attacks by simply not being in possession of any of that information.

The first point, that the changes are extensive and at least in some small degree affect all users, is addressed below.

What Changed

The changes we’ve made are fairly comprehensive and as a result it’s possible that you’ll have trouble signing into your account if you have inadvertently been taking advantage of a shortcoming in our previous account security methods.

Prior to about January 4, 2020, your Laridian account password was stored in our database in plain text. That’s a little unusual (and arguably unsafe), but it’s the result of the fact that our original website and database implementation was done by an outside company over 20 years ago when security standards for the Internet were very different. While standards have changed, making changes to security protocols while allowing thousands of users acquired over more than 20 years to continue to access their accounts is very challenging. So addressing this issue is something we have avoided for a long time.

Even though passwords were stored in plain text, they were (and are) encrypted when transmitted from PocketBible, and the database itself is behind a firewall. The encryption makes it unlikely that someone could grab your password by monitoring your Internet traffic, and the firewall isolates the database from the Web. Both the database and the server it is hosted on require secure account login, so it would be relatively difficult for someone to access it and view user passwords. Since we weren’t protecting any financial information, we weren’t strongly motivated to make this change.

There were three main problems in the old implementation:

1. Passwords used to be case insensitive. If your password was PASSword, you could log in with password, Password, or PaSsWoRd. This was apparently caused by the original programmer not understanding that the database was configured to do case-insensitive searches. When we discovered it later, we already had users who were inadvertently taking advantage of this misbehavior, so it became at least difficult, if not impossible, to easily change.
2. We used to truncate all passwords to 10 characters even if you entered more than that. If your password was password1234, you could log in with password12, password12#$, or password1234567890. The original programmer allowed for longer passwords in the database and in his code, but accidentally limited the length of password fields by the way pages on our website were written. Again, once we figured this out we already had thousands of users who were taking advantage of this without realizing it, so we couldn’t easily change it.
3. As mentioned before, passwords were stored in plain text in the database. This was the result of the naïve belief by the original implementor that password-protecting the database and the server was sufficient to secure this information. This turned out to be true, but we felt we could do better.

The new method addresses all of the above issues:

1. Passwords are now case sensitive. If your password is PASSword, then you must enter PASSword or you don’t get in.
2. The new method does not put a practical limit on the length of passwords. There is a limit, but you won’t encounter it unless you want to type for a long, long time. You could create a 1,000,000-character password if you want. It just wouldn’t be practical.
3. Your password isn’t stored anywhere.

Wait, what? If the password isn’t stored, how are you able to log in?

The way the new system works is that your password is run through what’s called a hash algorithm. This algorithm calculates a unique value that represents your password. So even if a hacker were able to gain access to the database, they would only have indecipherable numbers, not your password.

The has algorithm is one-way. That is, it’s trivial to calculate the hash value from your password, but it is theoretically impossible to generate your password given the hash value. Again, if our theoretical hacker had a list of hash values, they could not reverse-engineer those values and figure out the passwords that generated them.

When you log into your account, we run the password you give us through the same algorithm to produce a hash value, then we compare that number to the number in the database. If they match, you get in. If not, you don’t.

How You Are Affected

Because of the way we phased in the changes, you shouldn’t notice anything different unless you were accidentally using upper/lower case in a way that didn’t match your original password. If your password is longer than 10 characters, we’ll still use just the first 10 characters to log you in. If you create a new password that is longer than 10 characters, we’ll use the full password.

As mentioned before, changing the way passwords are stored and used on our site and in our apps affects virtually everything we do:

• Obviously, logging into your account on our website is affected.
• Viewing the list of books you own from inside one of our apps depends on PocketBible being able to log into your account.
• Synchronizing your notes/highlights/bookmarks with the Laridian Cloud depends on PocketBible being able to log into your account.
• PocketBible for Windows Desktop uses an older version of synchronization with our iPocketBible.com server, which is different than the other apps use and takes a different path to log into your account.
• Requesting a password-reset link from our site works the same way as before but internally is significantly different.

As a result, there could be problems in some remote corner of one of our apps or on our website that we haven’t discovered yet. If you run into any problems, contact us at [email protected].