[kcdc 2025] Passkeys: The end of Passwords and the Future of Authentication

Speaker: Mateusz Zajac

For more see the table of contents


General

  • Don’t need complex passwords
  • Phishing proof
  • Public key crypto _ biometrics
  • One tap sign in
  • Secure
  • Fewer breaches
  • Simpler flows
  • Lower support costs – fewer password resets/tickets
  • Lower fraud – starting to move to customer facing apps like travel. Not just finance
  • 1 billion people use daily

Problems with passwords

  • Easy to guess/steal
  • Phishing
  • Credential stuffing – if one account falls, others follow
  • Server breaches. Most common attack
  • Users have to keep track

Passwords vs Passkeys

  • Passkeys auto generates. Passwords type twice.
  • Passkeys can use face id
  • Passkeys don’t require reset. Password reset flow has many steps. Including memorable but different than last batch of passwords. 57% users forgot password after reseting. 30-40% help desk calls password reset related
  • 81% breaches involve compromised credentials
  • 51% of people reuse password
  • 2.5 million passwords stolen each week
  • Passkeys synced via iCloud
  • 92% users give up and don’t try to reset
  • 400 million google accounts use

2FA

  • SMS phishable
  • Push fatigue where keep getting notification until give in and click

Passkey

  • Pair of keys
  • Private key on your device
  • Private key kept safe
  • Phone creates a sharing key
  • Website sends challenge need secret key to solve
  • Use face id and solves
  • Sign ins are four times faster than passwords

Amazon login example

  • One time setup – your device creates a private/public key pair. Amazon stores public key
  • When try to login, Amazon sends a cryptographic challenge. This avoids replay attacks.
  • Your phone uses Face ID to confirm it is you. Then phone has private key sign the challenge and sends to Amazon. Amazon authenticates

Phishing prevention

  • Scammer tries with fake sight
  • Your phone refuses to sign because domain is wrong

iOS Code

  • WebAuthn
  • FIDO2 – gets url, challenge size, etc

Cross Device Sign in

  • Websitte generates QR code
  • Scan with phone. Uses bluetooth to verify physical proximity
  • Single use
  • Expires quickly
  • Private key never leaves device
  • Useful if want to log in from someone else’s computer

Challenge

  • If lose phone
  • Cross platform sync
  • Inconsistent browser support
  • Human factors – trust, education

Good references

  • w3c.org/TR/webauthn
  • fidoalliance.org
  • developer.apple.com/passkeys
  • etc

Informal Q&A

  • Two people had facial recognition not work
  • External device

My take

Great comparison and great statistics.

[kcdc 2025] The Amazing Features of Modern Java

Speaker: Venkat Subramaniam

For more see the table of contents


Switch

  • Showed switch with break missing
  • Turned it into a switch expression by changing the code in place.
  • Emphasized code more concise and not writing extra break
  • Can match multiple values
  • Can add {} and multiple lines of code with yield. Not recommended. [so glad he said not recommended}.
  • If use return instead of yield, compiler tells you what is wrong “attempt to return out of a switch expression” instead of what to do. [fun analogy about inlaws telling you what is wrong]

[i had more notes than this – record and sealed classes – i messed up saving]

My take

I missed some of this because I was getting ready for my session immediately after this. I’ve seen Venkat speak many times and am familiar with the content. I came mainly because Venkat is an amazing speaker and has great energy.

[kcdc 2025] Crisis Coding: Navigating Impossible Deadlines

Speaker: Drew Spencer

For more see the table of contents


Background

  • Works at a lab (MAWD Pathology Group)
  • COVID created imposible deadlines

Situation

  • Dealing with a global crisis
  • Everything needed to be done as soon as humanly possible
  • Deadline was as soon as possible before legacy software died
  • Big labs couldn’t handle volume.
  • Repurposed instruments and tried to scale up.
  • Database started failing
  • Needed more flexibility, wanted to develop own because unique needs
  • Off the shelf solution would have taken a year

True Deadlines

  • Some are arbitrary deadlines and some are true deadlines
  • ex: launch date for funding

Requirements

  • Scalable
  • Google cloud

Lesson: Deliver what you can, when you can

  • Deliver most critical items ASAP
  • Delivered first thing in 100 days. MVP was a single test
  • Two week sprints
  • Do not deviate from spring cadence to bring in new requirements unless you have to
  • Work closely with key users
  • Guard vigilantly against scope creep
  • Protect developers from themselves- “it’s not that much effort to do x”
  • User noted only one instrument for test. Don’t spend time/lose trust demoing something that wasn’t critical
  • Intellectual debt is better than a failed project – ex: hard coding things

Lesson: Things will go wrong; react accordingly

  • Move fast and break things. But understand what cannot break.
  • Went live on a Saturday because volume was lower
  • Ran with a test patient – Mickey Mouse
  • Were sending results by fax. Line was busy after first one. Learned need to queue and send out in batches every 30 minutes. Fixed by Monday
  • Things will go wrong; it’s not always your fault. User entered wife’s phone number and use was looking at his phone. User errors hard to account for

Lesson: Trust

  • Trust team – no junior developers because needed to know team could deliver
  • Continue to deliver – incremental delivery
  • Build trust with leadership and clients
  • Trust must be from the top down.

Result

  • Over 900K Covid tests
  • Mass test sites in KC area
  • Platform for schools and businesses

Other notes from end and Q&A

  • While there wasn’t a defined, there was testing fatigue and a drop off in quantify
  • Max 5K tests in a day
  • Crisis pace not sustainable; crisis must end
  • Burnout
  • Everyone was exhausted but people expected it as normal. Need to get out of crisis mode. Use that pace selectively.
  • Had two systems. Just did Covid tests in new system. Used legacy system for everything else. Reporting from both systems
  • Tried to keep 8 hour workdays as much as can, although more when close to deadline. Did work weekends. Tried to guard teams time with nighttime calls and only let thru when system down.
  • Pre-covid everyone worked on site. Developers were almost all remote (not local)
  • Drove tester crazy. Short deadline to test but quality still matters
  • Deployed a week after sprint ended
  • Banked flex days to take off after crisis was over One person went on a sabbatical to refresh

My take

This was a great case study. Different than the ones you usually see. It’s helpful that the problem was an actual crisis and not an arbitrary deadline. The learnings were well distilled. Interesting answers during Q&A.