From 5e4ea1ab47c50efaa605cb01902bb2acece0f3d1 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Sun, 31 Mar 2019 19:06:48 +0300 Subject: Change: make requirements list be less dense, space-wise --- yuck.mdwn | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'yuck.mdwn') diff --git a/yuck.mdwn b/yuck.mdwn index dd05a59..5924a44 100644 --- a/yuck.mdwn +++ b/yuck.mdwn @@ -138,65 +138,87 @@ Each requirement and sub-requirement is given a unique name for easier reference in discussions. * (SECURE) Yuck MUST be secure. + * (CREDSTORE) Yuck MUST be store credentials in a way that minimises damage if they leak. Credentials SHOULD be stored encrypted using a respected encryption algorithm (such as scrypt) and using per-credential salting. Or something stronger may be implemented instead. Additionally, all the credntial records SHOULD be encrypted for an additional layer of defense. + * (MFA) Yuck MUST support multi-factor authentication using secure factors. + * (PROTOS) Yuck MUST use secure protocols to authenticate users and API clients. + * (HTTPS) Yuck MUST NOT ever use plain HTTP, only HTTPS. + * (AUDIT) Yuck SHOULD undergo security audits, and general scrutiny. Audits SHOULD happen regularly. (This is not an absolute requirement, as it depends on the availability of competent auditors. Yuck is not a for-profit project, and may not be able to pay them.) + * (SECUREANDUSABLE) The Yuck developers MUST keep security at the highest priority, without sacrificing usability. + * (QUALITY) The Yuck project MUST aim for high quality, by applying development methods that are known to work for achieving quality, such as test-driven development, automated test suites with high test coverage, and code review. + * (HSCALABLE) The Yuck architecture MUST be horizontally scalable to very large numbers of concurrent users and API clients. + * (NOTUNSCALABLE) The implementation might not scale to very many users or concurrent users, especially initially, but the architecure MUST NOT prevent a scalable implementation. + * (ADMINFRIENDLY) Yuck MUST be flexible for system administrators to manage, and applications to use. + * (ADMINAPIS) Yuck SHOULD provide APIs for managing the entities and data it needs, such as for creating end users and API clients, or changing their credentials. + * (APPFRIENDLY) Yuck SHOULD enable applications to delegate all authentication to Yuck. + * (FREEDOM) Yuck MUST be free software. It MUST NOT require applications, API clients, and other software that works with Yuck to be free software. * (PRIVACYSTORE) Yuck MUST NOT store personal information it does not need. + * (PRIVACYLEAK) Yuck MUST NOT leak personal information. + * (PWRESET) Yuck MUST support the user resetting their password, securely. Possibly by supporting a random, single-use link that can be communicated to the user (perhaps via email) to allow them to change the password. + * (TEMPLOCK) Yuck MUST support locking an account temporarily, if it is the target of too many failures. This is to avoid an attacker from brute-forcing a password by trying many times. + * (TEMPLOCKNOTIFY) Yuck MUST notify an account owner of temporary locking, out of band. + * (ACLSIMPLE) It must be easy to understand and reason about ACL rules. It may be good aid this by visualising. + * (ACLTRY) There must be a way to test ACL rules: if *this* user in *these groups* does *this* operation for *this* resource, is it allowed? This may require additional support from the RP. + * (DISABLEACCT) It must be possible to disable an account (whether for an end-user or an API client) so that it still exists, but authentication cannot ever succeed. + * (KILLSESSION) It must be possible to kill existing web sessions to kick out someone who is logged in to Yuck. + * (KEYROTATION) The IDP MUST rotate signing keys so that a leaked key can be easily replaces. The IDP MUST have a secure way to distribute the key to clients. -- cgit v1.2.1