5

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.

UPDATE #1

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.

UPDATE #2

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.

Damaged Organic
  • 159
  • 5
  • 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 Mar 05 '15 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 Mar 05 '15 at 13:31
  • @Stephane: Public salt itself works fine in existing scheme, but it's more about usability than protection. While user have his secret passphrase in his head or whatever, this salt is used more like identifier. It's kind of a secure sequence as well, so I think I can refer to it as "password". – Damaged Organic Mar 05 '15 at 13:34
  • @tim: well, it could be other way around, but user is then **forced** to actually store his secure passphrase somewhere. I'd rather let him decide, should he store it or just memorize. – Damaged Organic Mar 05 '15 at 13:36
  • 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 Mar 05 '15 at 13:48
  • @tim You can use an eternal file to improve the security of a password-based system but, in order to do so, you must ensure that the data contained in that file is kept secret as well. Unless I missed something, in this scheme, you're only adding security by obscurity (hoping attackers do not know how and where the salts is stored) at the expense of usability. – Stephane Mar 05 '15 at 13:50
  • @Stephane: it is salt, and it's public. User should have salt and passphrase to perform some kind of action. So this salt is useless without passphrase. And I'm not trying to add extra security, but to make salt look more user-friendly by transforming it to something nice and native. Like image. – Damaged Organic Mar 05 '15 at 13:56
  • 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 Mar 05 '15 at 14:06
  • 1
    I, too am very confused by the scheme. – schroeder Mar 05 '15 at 17:42
  • All right, let me please update my question with a complete scheme. However, question is actually not about the scheme... – Damaged Organic Mar 05 '15 at 17:47
  • 1
    @Stephane: Some years ago I developed: [file2password](https://github.com/lepe/file2password) which is based on the idea that you can generate a password using the base64 "entropy" created by the file. You don't need to carry your file with you all the time. It can be stored in the cloud. It may not be a perfect solution but its better than using a simple password. One advantage is that uses only JS so its implementation is pretty easy. – lepe Aug 21 '15 at 00:52

4 Answers4

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.

Andrew Hoffman
  • 1,997
  • 15
  • 17
  • 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`? – Damaged Organic Mar 05 '15 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. – Andrew Hoffman Mar 05 '15 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. – Andrew Hoffman Mar 05 '15 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 :-) – Damaged Organic Mar 05 '15 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. – Andrew Hoffman Mar 05 '15 at 21:47
  • Please, see my update on the question. I think that there was a misunderstanding. – Damaged Organic Mar 07 '15 at 11:01
0

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.

Tom
  • 10,201
  • 19
  • 51
0

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.

Allison Wilson
  • 429
  • 2
  • 9
  • 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? – Damaged Organic Mar 05 '15 at 21:40
0

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.

munchkin
  • 393
  • 1
  • 5