openseced / auth Goto Github PK

• U-prove
• Stefan Brands' book on maths of U-prove

The students' reality is identity-based authentication with passwords that must be at least eight characters, upper and lower case, digit and special characters. This is reinforced every day and is so wrong.

How do we unlearn what is reinforced every day? How can we make them learn how it should be, how can we make them retain this? How long will they retain it?

• Intro + bootstrapping took 35-40 minutes.
• Authenticating took 45 minutes.
• Securing took 2*45 minutes.

• Passwords used to authenticate interactively
• Passwords used for key derivation
• Passwords used with password managers, see Project Password Managers.

This related to #7 #11.

We should have case studies: analyze authentication for

• streaming service,
• banking service,
• second-hand sales service,
• home-delivery service,
• payment service.

There is some detailed password coverage in infotheory/basics, maybe some of that should be moved here. It's good to keep those parts closely related to entropy there, that'll make that material better. Other things should move here, and a copy should be brought here too.

https://www.svt.se/nyheter/inrikes/bedrageriexperten-om-kurirbluffen-sofistikerad-phishing

The Private E-Commerce Company wants to strengthen consumer privacy in the area of e-commerce. We have three entities; the Seller, the Shipper and the Buyer. The Seller sells the Product to the Buyer. The Seller then ships the Product to the Buyer using the Shipper's shipping service.

Make the case concrete, like an online bookstore. How can we maximize security and privacy? I.e. principle of least privilege and data minimization.

When the buyer has paid the seller generates a public--private key pair, gives the private key to the buyer and the public key to the shipper. The buyer uses the private key to sign the receipt of delivery, the shipper can verify it's the right person and the seller can verify that the package has been delivered to the right person.

overview is currently quite narrow. The lecture given by Jøsang and Loutfi in Finse is good for inspiratoin.

It should mention Kerberos and anonymous credentials, e.g. Idemix.

The "securing authentication" section should be reviewed.

• Point out that anonymous credentials is like public key crypto, the stuff the server must store can be perfectly public.
• Needs a better story line.

Add authenticated-key exchange and authenticated key-exchange.

Since we must use password managers to cope with passwords, we might just as well replace the passwords with crypto keys anyway. Once we have crypto keys we can do anonymous credentials. There will be no leaked password databases as the server only stores public keys.

We need a lab that pushes the students beyond identity based authentication. What do they actually need to authenticate? Usually not the identity.

However, sometimes a password is the right thing, like protecting the password/key manager. (Sometimes a biometric can be used here, which is a password of sorts.)

• This should be clarified, specifically the relation between authentication and verification.
• We might also want to deal with other attributes than identity, more such examples should be added.

Evaluate user authentication from user--machine, machine--user perspective.

We should evaluate purely password-based authentication, two-factor authentication and key-based authentication (e.g. BankID), both from a security and a usability perspective.

• Identitfication and authentication (add attribute-based authentication) / Intro
• Bootstrapping authentication and recovery
• User--machine authentication
• Machine--user authentication
• Machine--machine authentication
• Time-of-check, time-of-use
• Securing authentication (break out password security to passwd).
• Break out passwords to passwd module.
• Break out biometrics?
• Add usability.

This is related to #1.

We cover some parts of biometrics. Maybe it's good to have that as a separate module.

We should have a lab where the students focus on designing user authentication. This is better than current state of passwd/pwdpolicies, where they just focus on passwords for user authentication.

We can provide a few scenarios for which the students should design the needed authentication --- after first identity the needs.

The time-of-check, time-of-use problem is general for all auth, better have that in the intro and let it come back in the other parts.

The area of authentication that we are interested in can be divided into these categories:

• user-to-machine,
• machine-to-user,
• machine-to-machine (#22),
• user-to-user (through machine).

There is some purely authentication-related parts in the usability overview, this should be moved here.

The passwd module is specialized on passwords, maybe we should move that coverage (at least detailed coverage) there.

Ask the students: how do you know I'm the teacher for this lecture?

This should be asynchronous. But I can use FeedbackFruits for the students to discuss it.

Possible ways to authenticate: I'm the same as with Sonja. How do they know I'm the same? Deep-fake? How do you know Sonja was the one to teach that lecture?

Use this contrast to talk about different forms of authentication in a new area.

Interesting?
https://phishingquiz.withgoogle.com

Add descriptive figures, e.g. for password guessing.

To ensure freshness we need challenge--response. Thus to make biometrics secure (i.e. authenticated) we need challenge--response: we give a challenge to the biometric sensor, which incorporates the challenge into the reported data. It's crucial that you cannot take this challenge and just process it with previously recorded data.

Currently it's just a traditional lecture.

This would be details on crypto protocols for authentication. Basically, we can reduce much of user-machine and machine-user to machine-machine due to the user using e.g. a smartphone.

We have Schnorr which is zero-knowledge. Add an example where the public key is not known, where you prove you know a signature on a public key for which you know the private key.

This would allow for greater modularity. There is also some material on federated identity management which can also be moved to its own module.

Like using the credit card information for authentication.

Add material on SSI and FIM.

https://www.reddit.com/r/CrazyFuckingVideos/comments/1087jtq/ukrainian_police_bust_a_bottroll_farm_used_to/?utm_source=share&utm_medium=android_app&utm_name=androidcss&utm_term=1&utm_content=share_button

Some students want to use MFA to protect a one-time code for a box to fetch a package.

Currently each session broken out from overview has the old abstract from overview as an abstract. Obviously this is not accurate anymore. The affected sessions are:

• intro
• bootstrapping
• user-machine
• something-you-know
• something-you-have
• something-you-are
• machine-user