Extending on PINSafe, described as: "Secure identification of a user in an electronic communications environment, wherein a host computer communicates with a plurality of electronic devices operated by the user. The user is issued a
user code, known only to the user and stored in the host computer. User identification involves the host computer generating a pseudo-random security string and applying the
user code to the pseudo-random security string to generate a
transaction code. The host computer also transmits the pseudo-random security string to one of the electronic devices which displays the pseudo-random security string to the user. The user generates the
transaction code by applying their known
user code to the displayed pseudo random security String. The user generated
transaction code is entered into an electronic device, then transmitted back to the host computer. Positive identification is achieved when the host computer's determined transaction code matches the user generated transaction code." PINSafe, now acquired by us, suffers from 6 flaws (some quite fundamental): 1 - Conceptual flaw - No offline support without caching (leaving the on-demand string lifetime out of the security equation) 2 - Implementation flaw - Trust in transport
encryption - HTTPS is easily hackable and interceptable, The PIN generated code can't, as such, be transferred back to the
server securely. A bad actor could use the string request URL to grab a valid TURing Image with the initially generated security string, and then cross it with the reply data on the form, capturing, not only the username, the
password and the OTC that can easily be reversed back into a PIN, compromising the entire
system. 3 - Implementation flaw - Storing of PINs with reversible
encryption, due to a clumsy approach to the legacy systems User&
Password, 2 field only,
authentication realm. 4 - Conceptual flaw - Humans are not to be trusted with secret keeping. Although PINSafe is designed to ensure "one is who one claims to be", and it clearly performs its job, this is conceptually naive as human beings are known to share PINS in efforts to fool the
system even when this promiscuous behaviour could render them in trouble… truth is, they fail to foresee complications until they materialise. 5 - Conceptual flaw - One point
verification / validation design. In PINSafe design, the
server generates the strings and the user, presented with the strings, uses its PIN to extract the OTC used in
authentication, and then presents it to the
server. The server is the only element here serving the
authentication process. 6 - Conceptual flaw - Binary outcome - There is either a pass or fail. There should be circumstances where the user would be either authenticated with restrictions or authenticated with trust warnings. Covering several trustable usages and / or coaction usage. SCOPE ePINSafe - EnhancedPINSafe This patent aims to solve flaws number 1, 2, 3, 4, 5 and 6 from above ABSTRACT enumeration. Assumption is that HTTPS has been compromised at all times and that further
encryption must be supported.
Encryption to be used is off standards and not discussed in this paper, as it's an implementation of 3rd party standards choice. The entire PINSafe mechanism is transited from the original patent, as the user receives a string of generated characters that he then uses the PIN in his possession, as a locator
algorithm, for the extraction of an OTC, by using the numbers on the PIN as a positioner on the string,
copying the character that the string has at that position, one by one, to generate an OneTimeCode. Offline generation of PINSafe securityStrings has always been done via a cache, maintained by and when a server connection was made available. An extended offline method was implemented for the Windows
client that, though obfuscated, still leaves open the possibility for a decompilation and
reverse engineering of the offline PINSafe generation routine, plus the storage and decryption of the PIN.