I'm currently thinking about a web-app that can go offline (after being online) and still be able to provide authentication to the user securely. (For example, in a multiuser environment, it's quite essential to prevent other users' access.)

Right now, I was considering a password-hash authentication with some salt, and just saw this SO question: https://stackoverflow.com/questions/7879641/user-authentication-in-offline-web-apps

But since this is a web environment, I have to assume that others have access to the source code of the app, and thus the salt itself is leaked. (Also, the attacker might use the hash itself to bruteforce the password itself.)

So...to summarize, my 2 questions are:

  1. Is salting effective even when it's leaked? I'm guessing no to the question, since it takes O(X^(m+n)) to bruteforce the unknown... and it gets worse when the attacker uses the password hash to bruteforce the passwwd..
  2. Are there any effective (secure) ways to authenticate the user?
  3. Any good way to generate a DES key for encrypting the user's data (and provide a way for the server to distinguish between tampered data and real one?)
  • 2
    If you use DES, you don't need to worry about any of that. An attacker will simply brute-force the DES key. Jul 30, 2013 at 10:14
  • 1) Salts are always considered public. and 3) If you use DES, you really don't need to worry anything about the rest.
    – tylo
    Jul 30, 2013 at 13:57
  • I'm going to migrateyour question to Security.SE in the hopes that you'll get more discussion and answers there.
    – mikeazo
    Jul 31, 2013 at 14:55
  • 1
    I'm not sure I understand what you mean by "...can go offline and still be able to provide authentication..." The nature of a web app is that if it's offline, it's inaccessible, and therefore not useful for anything, so clearly I'm missing something here. Can you add any additional detail about how you're expecting this would work?
    – Xander
    Jul 31, 2013 at 15:17
  • Doing encryption in JavaScript isn't going to be fun. Is there any reason your users can't just lock their computers or "switch users" when they walk away? Jul 31, 2013 at 15:57

2 Answers 2


I'll answer your "2" questions below:

  1. As for the salt: a salt is supposed to be public. Sometimes an extra secret value is used (e.g. by pre-pending to the password). This is often referred to as "pepper".

  2. Try TLS with client authentication. Use the credentials within the client certificate (after successful authentication & session establishment) to provide access control.

  3. Yes, it is possible to derive a DES key "in a good way"; use PBKDF2 with a high iteration count and large random salt. The DES key is however not secure anymore once it is used for encryption because of brute force attacks.


Generic answer: if password-based authentication can be performed offline, then the app necessarily contains all that is needed to decide whether a given password is the correct one or not. This unavoidably implies that by dumping the complete app code and contents, the attacker can "emulate" the offline server on his own machine, and try passwords at his leisure, limited only by the computing power he can muster (how many PC he will buy or rent) and the inherent computational cost of verifying every single password. This is called an offline dictionary attack situation.

At best, in such a case, you can raise the cost by using slow hashing (many iterations of an underlying hash function, or something similar) and salts (to prevent parallel attacks, cost sharing, precomputed tables...). See this answer for a complete treatment.

Offline dictionary attacks are a worry. Being in such a situation is not comfortable. If users accept a 1-second wait for authentication on their smartphone, then the smartphone CPU must necessarily be able to verify a password within one second. An attacker with a few good PC will then be able to "try" at least a few dozen passwords per second; make that a few hundreds if the hashing algorithm maps well to what off-the-shelf GPU can do, a few thousands is the attacker is industrious and went straight to some FPGA implementation. Also, the attacker is often patient, and can afford to wait one or two weeks before obtaining a user password. This adds up to, very roughly, one billion password tries for the attacker.

Training average users to choose passwords which will resist a brute force attack of one billion potential passwords, is hard. See this question for some discussion on the subject. On the other hand, if you get to choose the password (not the user), then select a sequence of 15 random letters: that's 70 bits of entropy, and this will resist long enough to deter attackers (a password space of size 270 is huge).

Note that salts are not meant to be secret, and are effective even when known by the attacker. A secret salt is not a salt, but a key. You cannot have that in your situation: one must assume that the attacker dumped and reverse-engineered the complete app code. To a large extent, your context is similar to that of password-based encryption: protecting the confidentiality of a piece of data, with regards to a secret password, without specific hardware.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .