[openscreenprotocol] [Auth] Length of Password

nigelcearnshaw has just created a new issue for https://github.com/webscreens/openscreenprotocol:

== [Auth] Length of Password ==
These comments relate to the authentication discussion of the open screen protocol. In particular I wanted to comment on the length of passcode discussion from the [last F2F meeting](https://www.w3.org/2018/05/17-webscreens-minutes.html#x09).

The question of length of (pre-shared) password being typed is raised and the vulnerability to brute force attacks based on a limited password dictionary. 

There is the prospect of a higher-level attack by restarting the protocol over and over with different guesses of the password in the hope that the attacker can eventually complete the protocol with the receiver and hence discover its password. This means the password dictionary should be large such that this cannot be achieved in a short time with a non-negligible probability (especially if there is a time limit between subsequent efforts). It also implies it should change from time to time to prevent cumulative attempts over say a year or so. This seems to be a trade-off between the ease of typing in a password on the one hand and exposure or discovery of the password during the password lifetime.

Another consideration, this time relating to the security of J_PAKE on the wire,  is to ensure the full security of the underlying numerical groups are utilised. J-PAKE requires the ephemeral secrets and the password to be mapped randomly over the interval [1-q] for integer groups  or [1-n]  for elliptic curve groups,  where q is the order of the multiplicative subgroup of Zp* such that q | p-1, and n is the order of the elliptic curve group. In the case of the password mapping, where the input code maybe too short to exercise the full range of q without further expansion, both sides of the protocol need to use the same expansion parameters and these may need to change from time to time.

For elliptic curves, values with a security level of more than 128 bits are usual and these require an underlying group of 256 bits such as NIST curve P-256. So 256 bits can be represented as a 32 8 bit character string. 

Looking at the characteristics of finite field cryptography (FFC)  based on multiplicative groups as used in other protocol using discrete logs in NIST SP 800-57 Pt. 1 Rev. 4, P53, a security strength of 128 bits can be attained with L=3072 and N = 256. (less secure values are more typically L=2048 and N= 224 or L=2048 and N= 256 for 112 bits, or L=1024, N = 160 for <112 bits). See algorithm in FIPS 186-3 A1.2.1.2. for a means to generate values conforming to the (L, N) relationship. Values L and N correspond to the bit length of values p and q in J-PAKE.

(See also NIST SP 800-131A REV. 2 (DRAFT), July 2018 table 4)

On this basis it seems the answer to ‘how long is the passcode’ is 32 x 8 bits, though how much of this is input and how much is conveyed by other means (static or dynamic) needs to be determined.



Please view or discuss this issue at https://github.com/webscreens/openscreenprotocol/issues/111 using your GitHub account

Received on Thursday, 4 October 2018 15:12:35 UTC