Secure Keystroke and Key Entry Log-in

Public manual-key-entry security has been lax since its 1970's inception: The challenge was key-sniffing; In 1980, I proposed a thin SafeCard© solution for bank-account access via vendor POS terminals, with built-in-IC encryption and digit keys for password and data, provided by the customer's bank--ensuring secure access; But, SafeCard© is decades late and the Internet needs it too... An immediate remedy is to use a visual auto-encryptor easy for the user to read and log-in but ineffectual of machine-time to guess

[Related: 26+2 key alphanumerics; and 16-key ZooMath Glorified Adding Machine do-all RPN calculator.]

Log-in password input-entry needs not only non-echo nonreadability (typically asterisks echoed in lieu of typed characters, exposing little information but that keys are depressed) and https-secure transmission (typically 40- or 128-bit SSL) but anti-keysniffing in the computer Internet "browser windows" and software. It is also wise to hide keycap fingerings from camera views ... But strongest simply altogether prevents direct knowledge of key-fingerings and key-values from being decoded, a "clear code" relying on what the enterer sees and thinks rather than does. (Cameras watching the eyes are also a concern, but not nearly as readable as key-fingerings, n'even two-handed all-fingers-downing slightly-sequenced or one-touching-only by clever manual dexterity.)

Short of off-PC encryption-equipment like SafeCard© using four short-stroke tactile-pressure keys (or futuristic finger-tip-nerve-impulse retroflection) for log-in, a web-page must provide an easy-to-read-and-use encrypting key-map not-easy for a virus-program to sniff, not-easy for a fast computer to decode, not easy for a human to assist reading, not easy for a camera to detect, not easy for anyone to know what the enterer is looking at or thinking-about: The enterer reads and translates the password through the keymap, key-by-key entering the encrypted version manually.

(Note also that, rovot-clicking on a map generates sniffable pointer-tracking-metric data.)

A fully digital solution uses extra-length passwords and key-entry cover-ambiguity: Ambiguity reduces by factoring the strength of the password, to functionally implement both passwording and entry encryption-indecipherability. (Ambiguity complexifies arbitrary decryption-reading of keystrokes.) Secure runtime script computes a changing keymap from built-in-hashed encryption, to prevent the map itself being sniffed, read, or retransmitted. More advanced solutions include read-write and lettered entanglement (ambiguity).

(Sophisticated user-silhouetting log-in might trigger on individual-fingerstrokes and report the generated code with stroke-timings.)

Delivery method - ambiguation - human-readability

An application pair --anti-key-sniffing and anti-display-sniffing "deodorizer"-- needs to get the server log-in page input-box to the browser and the keyed or rovot mouse-clicked password-input back to the server without divulging or letting surreptitious software decode the password or its encryption method used in that log-in transaction. Beyond that, it might be a picture, animation, or client-script-run visual impression, of a freshly constructed image-map of the password letters in barely human-readable wild font.

Artistically an image-map might come as an animated icon compounded of an original map, overlaid random alphanumeric-like lines and dots, with a random moving line, flicker and inverting video, various fonts, various positional offsets, as something people should have no trouble reading-through, but stymies computers; Or it can be done with encrypted script, and disallowing software to take clear-text snapshots.

To encrypt, a keymap displays several choices per key (32 most-distinct alphanumeric or 64 most-distinct cased alphanumerpunxic) and the enterer loosely-translates password keys ambiguously by deliberately arbitrarily picking among the many-- the web-server must have done its homework to translate back to a reduced-length still-solid password equivalenced ambiguous through the keymap.

Methods may include a rovot-click-map for exo'cryption-like translation of data entry of an 8-12-key password ... it should not be much think work-time.

The anti-key-sniffer half-application is easy: Any map of keyboard-keys from easy-to-read-and-find letters to scrambled-letters: each time different, and the URL or short-lasting cookie includes a 20-digit code-seed.

Or the reverse coding might be done with the rovot mouseclicks.

The method of a large irregular dis-array obscuring-font display of all multiple choices of the letters and numbers, and selection by looking along rows or columns or diagonals for any other, -and sending that instead,- makes maximum-work for any sniffer to read all the characters ... yet a simple visual exercise for a person using it for log-in.

But, A human key-sniffer presents an equalizing challenge requiring more entanglement-- 8x8 array, 4-letter password, 2-letter start, wildcarded, example

More powerful ambiguation - entanglement (simple)

A potential entangler serves a square array of password letters (wild-font alphabetic and numbers 3,4,6,7,8,9, visually most distinct) repeated uniquely jumbled in each row and column, and the client enterer chains-in following the password letters via rows via columns to the last line followed-out to its encrypted choice. The server provides a starting block (e.g. 8-letter) and a carefully crafted array for long (e.g. 12-letter) passwords, user-uniquely each log-in time. (It is slightly entangled by requiring the enterer to start from, either, top or side, each pass, effecting a single-wildcard encryption: which costs the server a factor of 2× at a slightly lower security ÷28 for log-in, but costs the sniffer a larger combinatoric factor ca 212 at guessing the password. And a second password is needful for changing user data.)

(The wildcarding combinatoric factor can be increased to 412 or 812 without enlarging the password, by allowing all four sides, left, right, top, bottom, for entering and exiting with distinct choices; but the starting block size should also be increased, probably 10-letter, and then the array to 64x64.)

Password length is longer than starting block size (i.e. a noninvertible matrix) to avoid single-instance-exposure to key-sniffing; The server ensures wildcarding by flatly-rejecting poorly wildcarded entry sets--and always-reminding of the rules...

Strong entanglement - 'skip jack' (*)

* (generic meaning, skipping a jack, picking-up combinations of jacks; leveraging ... not the US SkipJack encryption chip.)

A stronger entanglement than wildcarding, has the client user arbitrarily dropping one letter of the password in each chain-in pass;- Stronger than changing any one letter in-position because it affects the domain-base-position relation of all letters not just the one affected. (It is like breaking time-base-sync in a hologrammic transform, e.g. sinusoid matched-filter.) The server checks 12 choices (12 alternate positions in 12-letter passwords), while the sniffer has 1212 combinations.

(A variant entanglement inserts, an exclusioned letter, in each chain-in,- but which is essentially a back-folded, longer, password.)

Because significant visual-encryption methods take more time to log-in, their primary use may be at "personal bank-vaults" containing auto-login's that route around keyboard-sniffing via secure Internet trunklines, and already fully encoded leaving the "vault"-server.

Uploading a -new- password:

A password-setup matrix designed to be mathematically easy to deduce its use from its own key and the input keystrokes (it can be a large process for the rare occasion of updating a password) ....

Other methods include combination e-mail, p-mail, telephone, fax, each a whole sign-up password, which can then be simplified to one online using the entangler key-deletions or-insertions to specify the new....

Extreme measure may include changing the password each log-in by minorly-adjusting one entry, one letter instead of dropped, costing the server 1/8th more (8 starting-letters) and the sniffer ~24×1212 ... as this password is never systematized (matrix-solvable) in one log-in session, and changing it 'early' moves it beyond, and tends also to reduce the sniffer's observance-persistence, by relocations:-- allowing a potential 'escape route' of increasing securance .... [this will be updated till a significant -updater- solution is attained] ....

-----

Public Internet "browser" - secured design (desired)

A major trouble is the security of a URL itself: The user must know the precise account service domain name: It would greatly help to have the domain name, host name, and first-level application, in large letters while accessing a page containing a password-entry field:

I suggest, Alter the Address bar to display on pages taking passwords,--

  1. Double-large letters,-- taking the whole vertical space.
  2. Only its present host.domain.tld/application location,-- no subfolders, no options, no assist, n'autc.
  3. The exact end-of-the-line domain-name,-- no bank.dom*bogus.dom URL, n'autc.
  4. Unambiguous font distinction: O:0:o, G:6, I:l:1:7, 8:B:l3, rn:m, cl:d, VV:W, uu:w:vv, l-l:H, lVl:M, C-:G-, o:a:e:c, O.:Q:R, 1.:L:I., 7.:Z, 7_:Z_, Pn:Fh, ï:ii:ij:ü:ÿ, ∞:oo, ïn:ih, op:qo, ob:do, ch:oh:dn, x-x:x­x:xx, ii:iii, etc.
  5. Its application, http/https and lock-icon (ftps is not secure), and always "ALERT: NON SECURE" http/ftp/telnet password.

  6. Use a special non-letter-fill in the password fields.

  7. Alert "ESCAPE THE FULL SCREEN", to establish the procedure of manually un-invoking full-screen, to accustom users to act;
  8. Uninvoke the full-screen feature again to establish the user-expectation for account log-in;
  9. Advise "WAIT: DO NOT ENTER PASSWORD" until a password field is selected; then "ENTERING PASSWORD" when it is.
  10. A nice trim color indication of this feature.
  11. And contra-color trim when ml-layers are present.

  12. Disable external-frame event-capture script-linkages.

  13. Password fields, especially https-secure, should be only selected, not enterable: for entry done altogether in the Browser skin.
Beyond that: servers must implement reduced-sniffibility passwords, and prevent account history alteration on weak log-in compliance, And, logout-and-disconnect on 'browser-window' close-or-change, to remedy a major brand of Maintenance Mode https-login-capture, And, advise of misentry-instance-counts (inasmuch as there should ultimately be none at all), And, better-help authenticate users by two-part/multistage passwords, as 'The One-who-gets-both-correct' (or by silent stages)...

-----

A premise discovery under the title,

Grand-Admiral Petry
'Majestic Service in a Solar System'
Nuclear Emergency Management

© 1980,2004-2007,2012 GrandAdmiralPetry@Lanthus.net