Currently the instruction reads that students are allowed to work in groups of two.

Working in groups is definitely better for learning, but it's less good for examination. What is the purpose of the lab: for the students to learn the most or be examined on having fulfilled the lab?

https://www.grc.com/sqrl/sqrl.htm

Look into this. Apparently they are referred to something else when they go to JtR's download page on a Windows machine.

Password guessing in its own right is not particularly interesting. The interesting ILOs come from the pwdpolicies seminar right now. However, the pwdguess lab is an interesting tool, thus it can be included in the seminar instead: something along the lines of using it to evaluate policies.

The seminar should also be steered more towards exploring, applying and evaluating research related to passwords security.

Update the README to follow the OpenSecEd format, see e.g. pricomlab.

Alice has chosen a password $p\in P$ in the password space $P$. Let's assume that $\Pr_P(p) = 1/|P|$. If Alice employs a password system due to regular password changes, she chooses the new password $p'$.

While $\Pr_P(p) = \Pr_P(p')$ might hold true, $\Pr_P(p'|p)$ will be close to zero.

This isn't at all worked through right now, it's just the sketch of an idea. It's probably better to reason informally on this one.

Lennart's suggestion for improvement after running it this year:

Förslag till förbättring av seminariet är följande:

• Ett 45 minuters-pass med diskussion kring paper och policyer,
• Rast
• Gruppuppgift i grupper om 3-4, där varje grupp får i uppdrag att
  utforma sin egen lösenordspolicy utifrån de diskussioner vi haft under
  förmiddagen. Varje grupp ges därefter 5 min att presentera deras
  resultat och ett par minuter avsätts till att analysera deras policy.

Other suggestions for the last activity might be #3 and #4.

Add a part where the students redesign the authentication of a service, to think outside the password box.

Maybe replace it with

• IRMA
• Idemix on Hyperledger Fabric, but just documentation

https://www.schneier.com/blog/archives/2019/06/risks_of_passwo.html

We should add some more of the cracking programs used in the research papers to the pwdeval image.

• rainbowcrack: sudo snap install --channel=beta rainbowcrack
• Georgia Tech's PARS, demos here

Current version of the pwdeval lab/seminar has no password cracking, shall we reintroduce that?

The notes should be turned into notes summarizing the relevant results from the state-of-the-art of passwords research.

This is worked on in the pwdanalysis branch.

In \subsection{Introductory reflection} students miss the part
"Start by comparing how long a password consisting of lower- and upper-case letters, numbers and special characters must be to have the same strength as a password consisting of three and four randomly chooses words, respectively."

Possible need to reformulate the question?

There are some update in pwdeval/guessing.tex, e.g. added a Docker image with the cracking tools. Those should be backported to pwdguess.

https://latesthackingnews.com/2020/03/23/researchers-find-security-vulnerabilities-in-some-of-the-top-password-managers/

Is this the simple solution to password re-use? https://nakedsecurity.sophos.com/2018/10/17/is-this-the-simple-solution-to-password-re-use/amp/

We should provide a Docker image for each lab. Then a lab computer only needs Docker and access to Docker Hub.

• https://monitor.firefox.com
• https://haveibeenpwned.com/
• https://www.theregister.co.uk/2019/02/05/google_leaked_passwords_chrome_extension/

From @dbosk on September 11, 2015 12:7

Instead of giving a few password hashes to crack, would it be feasible to let the students work with the hashes of leaked password databases? Maybe a class-joint effort to crack all passwords in a database, or a first-to-crack-most competition?

Copied from original issue: dbosk/passwd#1

Add encrypted data in addition to the password hashes. I.e. brute force PBKD-based encryption key.

We must work out how one can run GUI programs in the container.

• Camenisch et al.'s distributed password scheme.
• Greschbach et al.'s decentralized password scheme.

Right now we have the instruction. Create supporting slides (i.e. a slide version of the instruction).

The Password Hashing Competition recommends Argon2 for password hashing.

There are many available password managers, some more usable than others.

Evaluate the usability of various password managers and compare to its security.

We want the students to crack their own password. Provide a service where they must "log in" with their university account to fetch an individual password hash. The service merely computes the password hash of the supplied password.

We should make a clearer distinction between the hard work of social engineering and advanced persistent threats.

Now the first part focuses on password policies, the second part focuses on alternatives to passwords.

A better order would be to first consider alternatives and when passwords should be used. Then as a second step focus on password policies for those cases.

If we can find what password policy was used by a service at the time of when their database was leaked, then we can compute the entropy of the passwords under that password-composition policy.

The entropy should be computed in similar way as in Komanduri et al.'s two papers.

Extend pwdguess to estimate how much easier a password is to guess knowing the policy. This should be possible by computing the reduction in entropy that the policy yields.

This shows the importance of studying every password-composition policy before using it. It connects well with the usable passwords papers they should read in pwdpolicies.

• Bonneau, "The science of guessing: analysing an anonymized corpus of 70 million passwords", S&P 2012.
• Zhang et al., "The security of modern password expiration: An algorithmic framework and empirical analysis", CCS 2010.
• Weir et al., "Testing metrics for password creation policies by attacking large sets of revealed passwords", CCS 2010.

Particularly, revise the entropy parts.