Strong cryptographic protection, without headaches.
When it comes to security, software professionals have long considered passwords a measure of last resort. Try asking your IT crowd, “do you use a password to remotely access secure servers?1” The answer: of course not. Because private keys provide a superior and fundamentally different kind of security than any shared secret (which a password is).
Somehow, though, passwords remain prevalent. Even when assets have high value (i.e. online banking), service providers require passwords. This is done despite obvious weaknesses in the password model2. We must use passwords, even if we are tech-savvy and would prefer something more secure. As a result, a whole ecosystem of password managers and second-factor applications exists, to make the fundamentally insecure password model “good enough”.
Our product Beyond Auth uses asymmetric cryptography to provide the best available security. A cryptographic challenge replaces a password prompt. Each challenge can be fulfilled only by the holder of a private key3.
Key management and cryptography have a reputation for complexity. With this in mind, Beyond Auth is designed to make best practices seamless. A user with low-value assets need not be aware that a secret key authorizes their activity; while a user with high-value assets can configure a robust scheme involving multiple keys. The application developer, importantly, needs only one authorization model capable of supporting users across a broad spectrum.
Beyond Central’s design is uniquely powerful:
Decentralization Ready - A single authentication model that works for a single authority, or peer-to-peer.
Automonous - Each peer opts into a secure scheme, which can be more convenient for low-value assets and more secure for high-value.
Verifiable - Modern cryptography and robust data structures ensure consistency across peers and tamper-proof activity logs.
Please reach out to learn more about Beyond Central’s authentication and authorization product.
If “yes”, consider posting to job board. The answer should involve a public/private keypair. (If that private key is protected by a passphrase, even better.)
[return]Imagine the form rejecting your password because its too short (or, weirdly, too long), or too lower-case, or too capitalized, or on and on and on…
[return]- Or, using “multisign”, several holders of multiple private keys. [return]