I seek guidance on interesting issue. Recently I've been searching for password alternatives, not because of the security, but to be more user-friendly.

In one of my projects user receives 128 bits base64 encoded salt as security token, which could be safely transmitted over social networks, messengers, sms, etc. When user decides to perform certain actions, he enters this public salt alongside with secret passphrase. Now, this 22 random character salt looks unpleasant and raw for the end user, it's difficult to distinguish one security token from another (user can have many), but easy to send, as it is just a string.

My general idea is to:

  1. Using 128x128 image, each pixel of this image is somehow binded with corresponding value from base64 with reference to next pixel of a sequence (details currently irrelevant), to produce something that looks like QR code from salt;
  2. Adding, say, gravatar as second layer on top of it, to make it visually recognizable.

My questions:

  1. Is this approach reasonable from usability point of view? It's harder to send image than string, I suppose.
  2. Is there any other way to make salt look more user-friendly?

Searched all around for answer. Would greatly appreciate any help.


I've found an example on Defuse Security, that generally reflects the scheme that is implemented in my project:

Encryption Process

As a result of the encryption process, end-user gets link, and path is actually represents salt - OwkXSVW8R5NTv3jGyAvnjy. This is the ugly stuff I want to transform into image, so it will be secured but still easily distinguishable for users, so my questions remain relevant.

Hope this will help to find out how.


I believe that question is misunderstood.

In my project, user have usual password, and some salt, persisted in DB, but that salt is just used as identifier. So, salt is not something that should be kept secret, and generally, salt is not secret. From Andrew Hoffman answer, unless you've got photographic memory, salt is something he has, and password is something he knows.

But the problem is, salt is not user-friendly, it looks heavy, and it's hard to distinguish multiple such salts at a glance. With that I think what salt can be transformed to that will look and feel good. For example, like Google ReCaptcha of version 1 and version 2 - it accomplishes same task, but simple click is more user-friendly than entering some symbols from picture.

I don't want to be annoying with that question, but please, just accept the fact that I'm not inventing my own salt derivation mechanism or security system.

  • 5
    I fail to see what you're trying to protect against with such a scheme. It seems that you're unwilling to store the salt along with the database and thus you offload that storage to the users. As described, and if I understand you correctly, your salt isn't secret at all and therefore doesn't add any entropy to the user's password, it just works like a regular salt value.
    – Stephane
    Commented Mar 5, 2015 at 13:27
  • 1
    @Stephane I agree. But I think it would be interesting to hear answers if the image is used as a second, private password instead of as a public salt (as the title of the question suggests). My guess is that it's quite good from a security perspective (an additional long, secure "password"), but quite bad for the user experience (eg has to carry the image around on a usb stick).
    – tim
    Commented Mar 5, 2015 at 13:31
  • 2
    @KidBinary I'm not saying salts do not work, I don't see the added value you have by having the user store it instead of storing it along with the password. Either you consider it secret data (and therefore it shouldn't be stored on a public site) or it is not a salt but pepper and it should be kept secret.
    – Stephane
    Commented Mar 5, 2015 at 13:48
  • 3
    How does forcing the user to store the salt value instead of storing it in your server (which is the standard pattern) making it more user-friendly ?
    – Stephane
    Commented Mar 5, 2015 at 14:06
  • 1
    I, too am very confused by the scheme.
    – schroeder
    Commented Mar 5, 2015 at 17:42

4 Answers 4


I believe you're confusing the purpose of a salt. You can derive a salt from an infinite amount of ways, but that doesn't change the purpose of the salt. And for the salt's purpose, it need not be secret.

So when reviewing critiques on your salt derivation, just understand that you're getting this feedback based on the purpose of the salt.

Other than that, user authentication can be very broadly generalized by something you know, or something you have. An image falls under the category of something you have.

Keeping that in mind, its fun to experiment and be creative with custom authentication schemes, but these schemes have not been hardened or analyzed for weaknesses, and for that reason, they should not be used in a production application.

The security industry is sort of like the FDA. It's not that you can't make a new, effective, safe drug, it's just that yours hasn't passed inspections. Inspections are costly, and if the problem is already a solved problem, we can't be arsed to inspect yours.

And that is why we generally respond, unfortunately in a brash way, of don't roll your own security. It's a solved problem.

  • Let me please ask you: do you think that scheme above, from Defuse Security, is good enough? Are they deriving the CSPRNG, which is salt, in a right way, by using /dev/urandom? Commented Mar 5, 2015 at 21:08
  • This is client-side key-stretching, so the image given is a little confusion, but as long as you understand that orange Server CSPRNG box represents a nonce from the server, then yeah it looks fine. Its basically challenging the client to produce a stretched hash that matches the one that the server produces. This can be useful for when authenticating over an insecure pipe, your password never leaves your computer. Commented Mar 5, 2015 at 21:16
  • 1
    Well, maybe the image isn't doing that.. The image is very confusing. :\ If authenticating over SSL, I don't see a benefit to client-side stretching. Commented Mar 5, 2015 at 21:22
  • Yes, hashing/encrypting on client is something that confuses me as well; hovewer, I can assure you, that I understand things about salt, and I'm not trying to generate salt from image - in fact, I want to create image from salt, to make it look nice for user. And I'm not trying to invent my custom authentication as well :-) Commented Mar 5, 2015 at 21:36
  • I think that's what is most confusing, because calling something a salt implies acceptance criteria based on what it is salting. But largely, salt, pepper, and nonce are the big ones. Unique salt for passwords, not secret, must be persisted. Pepper is for systems to make the system unique, not a secret, must be persisted. Nonces are for client-server challenges and shouldn't be reused, but also not a secret. What you're describing isn't really any of these. Commented Mar 5, 2015 at 21:47

If you are interested in looking at an already established method that is similar to what you are suggesting: Dell Secure Works already uses a QR code for first time authentication for new users. After registering on their site and downloading a certificate, they then create a QR code that, in coordination with Duo Mobile, requires you to read the QR code with your smart phone and then Duo Mobile generates a code based on that QR code for you to enter.

  • That is nice to know! But still, it requires user to posses smartphone. Not everyone got it, but almost everyone got an account on FB or else, and can transfer image around, don't you think? Commented Mar 5, 2015 at 21:40

The salt itself is used as an addendum to the password such that the ciphertext of the password is resistant to the usual cracking attempts that use well known words & phrases to lower the keysize, which is why the salt is a random string of some sort. In any case, what this means is, you could base the salt on anything, images, b64 encoded encoded word files, but the caveat here is the use of a recognisable image as a salt might confuse a user that the image is an indication of some kind of validity/seal, other than the fact that it should be entirely random.


The main issue with using files instead of passwords is that it changes the philosophy of the whole thing.

A file is something you have while a password is something you know. These are not the same thing. Therefore, you cannot replace one with the other without critically evaluating your entire security scheme.

If your authentication is based on a non-secret username (or an e-mail), the account security now rests entirely with a file that can be copied, stolen or lost. Not that passwords can't get spied, keylogged, or forgotten - but again these are not the same things. One important difference is that even if you steel my notebook or my phone, my passwords aren't there. But your security token files would be.

You must log in to answer this question.

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