Problem: current python code requires group code and user name, and are likely to get checked into repos, e.g. if students are taking care of their code properly. For jupyter notebooks, there is no convenient way of passing the secrets via env variables, so they have to be coded in directly.
Proposal: generate a one-time use code associated with every booking, and allow it to be traded for the activity, without being logged in. This avoids leaked codes giving away user names or group codes. Cracking an 8 char code should take a few hours, longer than most sessions, although longer sessions could be given a larger code. Recent cracking times suggest 8 chars with upper and lowercase and numbers should take 7 years to crack, while 6 of the same would be 15 hours. The actual numbers are slightly different because we are looking for a hit on a list of possible codes currently active, not just a single one. To a first approximation, for 100 experiments, 1/100 of 7 years is 25 days, so this could be acceptable. Usual rate-limiting in nginx could be used to further delay attackers /reduce load from brute forcing.
Prioritisation: currently somewhere between nice-to-have and must-have. If we are launching to a large class of python users it would become must-have, in my view.
Problem: current python code requires group code and user name, and are likely to get checked into repos, e.g. if students are taking care of their code properly. For jupyter notebooks, there is no convenient way of passing the secrets via env variables, so they have to be coded in directly.
Proposal: generate a one-time use code associated with every booking, and allow it to be traded for the activity, without being logged in. This avoids leaked codes giving away user names or group codes. Cracking an 8 char code should take a few hours, longer than most sessions, although longer sessions could be given a larger code. Recent cracking times suggest 8 chars with upper and lowercase and numbers should take 7 years to crack, while 6 of the same would be 15 hours. The actual numbers are slightly different because we are looking for a hit on a list of possible codes currently active, not just a single one. To a first approximation, for 100 experiments, 1/100 of 7 years is 25 days, so this could be acceptable. Usual rate-limiting in nginx could be used to further delay attackers /reduce load from brute forcing.
Prioritisation: currently somewhere between nice-to-have and must-have. If we are launching to a large class of python users it would become must-have, in my view.