1

Security questions are well known/widely considered to decrease security or otherwise create more problems (e.g., remembering gibberish), but sometimes I am required to have and answer them anyway. While that has been discussed many times before so I won't rehash the debate here, I'm a fan of passwords that are both secure and can be easily (re)generated so what I would like to do is to answer security questions with a portion of my pgp signature for the questions themselves. However, this leaves me with two issues I'm not confident about:

  1. if there is anything I'm missing that may actually make this less secure or less reproducible (different gpg versions or default algorithms, etc?) than I might think it to be, and
  2. where to extract the portion of the signature from, considering anything like the pgp header and the fact that the full signature is too long to realistically use.

Currently, if I use echo -n 'What is the air speed velocity of an unladen swallow?' | gpg -s --clearsign, I get:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What is the air speed velocity of an unladen swallow?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJaUnsoAAoJEAsnyIE5nAz6NLQP/2Yb33we/32eyWhHoCcYpzQI
0Si5AD+BJCrpcKgAehKdkx/eaHPKfTX55cxT23qk14XiLwnDqSsK/oPazuUwUIoP
brWkgqXj2G2YhQkBKe/WaEafbi3J7kmeddrmpaFrAkKkYYdFcC8zXtH9YcpM5OB2
kMava8oO0K6exoY4r2Fa9mIiOHrFZXkbtY9NuOvxhhOLmAeQolJ7WBdc+mt/Pmwv
0YIWlJhLgxxqqtXTlHXNNbatqkClAE1DB48FyyP3Mi8P8Ny+3z6ntDtwZezF+Lc4
67hWsUzjZ24E4Ww0CLquFTomNscuTFJRnAKJE02ctDixuz17zZxaliQBXdTrA43k
OUr+d9P2OdJXNPA0H9GQV9T+6CrHXM3dRXzrpSTrXzg7ZM8EWDB2b9iPp5b60KmE
/IwG0ijWH3B90gXJeGW2KeUm8qhH6AYBeXG+Yv2+9tB6T7KYETMku+FKgh61O6MJ
hYnQ7YMRhf8WjZw6m+jZ3knn0tIYqwszlJ7nJ0qlYlMsY9YzJkvKTpGQLHxQqDJv
ZraIbgPJuPJ1uT+qbbWk+QgOpehAyAFC/3aI57eqI/3poKl2/2f3QMsw7yRPnN/s
HeIvXhEVBqcOb7pfI3i6pT9f01QG5u16/vAKf6pq9WOuVTCeH5CP0t0xZ3eF+kJ+
m4C4rL/Q+uSexZL9IQ07
=jh/a
-----END PGP SIGNATURE-----

What I would like to do is take maybe a 16 character long snippet of the signature to use as my answer that would be in a consistent, easily found location so that I can reliably reproduce my answers to all future security questions, but where should that be? At least the first 18 characters seem to be the same regardless of input, but that alone is not enough to convince me to just discard the first 18 and use the next 16.

Can anyone address the above two concerns?

UPDATE

This question was originally hinged more on PGP being perceived as the potential solution to my problem, which was shown to not be suitable for the reproducibility requirement. However, I still like the idea of treating security questions similar to challenge-response authentication with the security benefits typically gained through PKI approaches (e.g., verifiability, non-repudiation, etc). In absence of such a solution, HMAC may be a viable alternative, but it reduces itself to being more of just another password (something I know) instead of a publicly verifiable response based upon something tied to my identity like a key (something I have). While this isn't quite an MFA question, I would like to know if there are any other possible approaches that could get me closer to what I had imagined?

1

The format of a PGP signature is a base-64 encoded message containing a number of fields, many of which are fixed or predictable. (e.g., key identifiers, algorithms in use, length fields, etc.) Additionally, the signatures contain timestamps, so if you regenerate a signature, you are not guaranteed to get the same values. PGP signatures are not deterministic, so are not a good fit for your use case.

If you want to do something like this, I would use an HMAC with a single secret to generate the answer. However, if you do just that, then two sites with the same security question get the same answer. (No worse than your original proposal, nor the traditional security question implementation, just a note.)

You can do something like the following in python:

import hmac
print hmac.HMAC('secretkey', 'What is the air speed velocity of an unladen swallow?').hexdigest()

Which gives 0e348e81ee5460ef138f7ec3ac9431de as the result. Without secretkey, an attacker could not reproduce this. Obviously you could wrap this in a small script to make it easier to use.

OTOH, the common solution to this problem is to store the answers in an a password manager. I used to use rather profane answers (more or less unrelated to the question) for security questions -- I stopped after the first time I called a bank and they wanted the answer I setup online told to them over the phone.

  • Fields with timestamps wouldn't produce a new problem, as like before I would still simply need to know enough about the structure of the encoding format to know where whatever field contains the message itself starts and extract from there. However, reading up more about the non-determinism you mentioned, it seems the real problem is that it apparently is designed to use a nonce to ensure that non-determinism. I didn't realise this, but I saw it discussed here: security.stackexchange.com/questions/85913/… – Hiko Haieto Jan 7 '18 at 22:48
  • No field of the signature contains the message itself. – David Jan 7 '18 at 22:54
  • Playing around with this some more, I'm left to presume that (my version of) gpg may be determining the nonce via the current date/time. I can regenerate the exact same signatures using faketime and a set date, but I can only assume that this is an implementation decision of gpg that I wouldn't necessarily be able to safely rely upon. I did like the authentication qualities I could get via PKI though (especially considering the intended purpose of security questions), but an HMAC would not provide that (e.g., non-repudiation, etc). Is there an alternative/better way to achieve that? – Hiko Haieto Jan 7 '18 at 22:55
1

There's a lot going on with GPG signatures; I would absolutely NOT use them for this purpose.

As @David mentioned, an HMAC is a reasonable way of handling this; openssl from the command line can do it; I would suggest that openssl is a reasonable alternative to gpg.

echo -n 'What is the air speed velocity of an unladen swallow?' | openssl dgst -sha512 -hmac MyKeyForAll

gives, for me

  4e423843133900407cab86527c7f17cd231cfa51a8bd21fdd8ff99aca2af19b9bbbc46c331326f712c25fab244ec5827d6430d5939c054b407010f1a470f9696

and you should too, on any computer, on any software compliant with RFC 2104 that supports HMAC-SHA-512 (assuming byte encoding is identical).

Changing either the password or the key changes the result dramatically.

A superior method is PBKDF2 or another properly iterated technique; PBKDF2 in particular is built on properly iterating an HMAC!

In my Github repository I have several implementations of PBKDF2 which run under both Windows and Linux (in various languages and with various libraries).

In these examples, you can increase the number of iterations to force an attacker to spend more effort on each of their own tries. For example:

  pbkdf2 -a SHA-512 -p "What is the air speed velocity of an unladen swallow?" -s MyKeyForAll -i 1310720 -o 64

takes about 2 seconds on my laptop using my OpenSSL based executable, and generates

  b45dc81933b8221ac69785f867e1ddedf6954e99f14a28bf41bd2f5f5f590e589f6b3b9f129c9cc9863deb412872fd8137478c729b5c01f5ac258699c0d5b141

just the same as every other valid PBKDF2-HMAC-SHA-512 implementation will (in varying amounts of time - PolarSSL and CSharp both take about 3 times as long).

A little playing with any of the source code should result in the ability to generate Base64 output if you like.

In every case, either the password or the key/salt MUST be a long random string.

An even more superior option is to use something like Keepass to generate long random passwords for each need you have, and have it copy/paste/autotype them in for you.

  • As indicated in my previous comments, what drew me to considering PGP was largely PKI. The nature of security questions and (albeit poor) assumptions administrators make regarding them seemed similar to challenge-response authentication. While their infallibility is greatly overestimated by admins, I figured I could do better with (theoretical) verifiability and non-repudiation. Though I can use hmac/pbkdf2 if no PKI-style solution is possible, that takes what I just described and turns it instead into just another password (with possible salt) due to it being reliant on the new secret key. – Hiko Haieto Jan 8 '18 at 7:58
  • I'll update my question accordingly, though if no solution comes up that would provide something closer to what I had envisioned, I do think I'll fall back to the hmac approach, perhaps with the secret key generated off my private key or similar. Also, I agree with @David that password managers are one of the most common alternative solution to this problem, but I do not agree that they are an inherently more superior one, and I had expressed interest specifically in having reproducible password generation without sacrificing the security of the result. – Hiko Haieto Jan 8 '18 at 8:18
  • If you really want to use PKI, you could investigate using the OpenSSL RSA functions directly; the command line interface is more in the way of an example than anything else, and thus may be fairly repeatable. Or it may not. That said, for this purpose, your "private key" is nothing more than a long, involved passphrase, since there is no other aspect of PKI in use. You might as well use PBKDF2 with a "key" of a the contents of a cryptographically random file (generated with GPG or OpenSSL or whatever). – Anti-weakpasswords Jan 9 '18 at 4:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.