Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Authenticate a user without a username, password, or database

Authenticate a user without a username, password, or database

How do you authenticate your users? Authentication is such a common feature we don’t even think about it anymore. Let’s challenge the status quo and authenticate a user with, well, nothing. Not even a database, and no API in its place. Do we need databases at all? Let’s talk.

Developed an application exploring the possibility of signing in without a username, password or a database on the web using Elixir/Erlang. I shared this as the closing keynote at Rubyfuza 2019.

Google slides: https://docs.google.com/presentation/d/1XJiBXD6uzWaFYbTXqacBmQZZEuicYN_CcSc2JDmcpUA/edit?usp=sharing

Simon van Dyk

February 08, 2019
Tweet

More Decks by Simon van Dyk

Other Decks in Technology

Transcript

  1. Claim Verify Store How would you do identity claim? a.

    Don’t be silly, just use OAuth b. Gait analysis c. Use their face d. Security is a lie
  2. Claim Verify Store How would you do identity claim? a.

    Don’t be silly, just use OAuth b. Gait analysis c. Use their face d. Security is a lie
  3. Claim Verify Store How would you do identity verification? a.

    Obviously a blood test b. OAuth, you will be assimilated c. Send them an OTP d. Fingerprint or retinal scan
  4. Claim Verify Store How would you do identity verification? a.

    Obviously a blood test b. OAuth, you will be assimilated c. Send them an OTP d. Fingerprint or retinal scan
  5. Claim Verify Store How would you do identity storage? a.

    Throw it in a file - that’s not a database is it? b. Mechanical turk: an army of humans write it out on paper c. Machine learning serverless blockchain™ d. Keep it in memory and never let the server die
  6. Claim Verify Store How would you do identity storage? a.

    Throw it in a file - that’s not a database is it? b. Mechanical turk: an army of humans write it out on paper c. Machine learning serverless blockchain™ d. Keep it in memory and never let the server die
  7. Claim Verify Store Facial recognition One time pin Memory storage

    Slack’s “magic links” or an OTP sent to an email address Erlang process storing face to email mapping in memory Face to email mapping used to identify a user
  8. Nada Faces API Nada App AWS Rekognition Sign up AWS

    S3 { selfie } { face_id } { email selfie } Claim { email face_id } Store { otp } Verify
  9. Nada Faces API Nada App AWS Rekognition Log in AWS

    S3 { selfie } { face_id } { email face_id } Store { otp } Verify { selfie } Claim
  10. Claim Verify Store Face to email mapping used to identify

    a user Facial recognition # @ Face Face ID Email Image
  11. Claim Verify Store One time pin Slack’s “magic links” or

    an OTP sent to an email address [email protected] [email protected] thisappdoesnothing.com/djtufy TO FROM
  12. Claim Verify Store One time pin Slack’s “magic links” or

    an OTP sent to an email address SUCCESS!
  13. Claim Verify Store Memory storage Erlang process storing face to

    email mapping in memory Erlang VM Web server process Agent process ...
  14. Claim Verify Store Memory storage Erlang process storing face to

    email mapping in memory Erlang VM Web server process “a7j3hgdg”: “[email protected]” “jmd739sh”: “[email protected]
  15. Erlang data stores • Mnesia • ETS (Erlang Term Storage)

    • Process state (GenServer/Agent) • *Riak
  16. • Are there relationships between the data you store? •

    Are you storing time-related data? • Do you need to be able to look at the database in the past? How do you intend to query the data?
  17. • Relational • Object / Document • Graph • Key-Value

    • Time series • Fact tables Typical data storage options by query