Create login flow for PendulumPay web app

[prayagd]

As a user, i should be able to login on the web app

Acceptance criteria

• on visiting the PendulumPay web app
• Now clicking "Login" button on the top right corner of the screen
• on /login show two fields
  • "Email" - only emails should be accepted here and no other text
  • "Password" - only passwords should be accepted in this field
  • Show a "Login" button below these two fields, the button should be enabled only after the two fields are filled
  • On clicking the "Login" button,
    • if the submitted Email and Password dont exist in our database. Show error below "Login" button, text is "Incorrect data, Please try again"
  • on clicking the "Login" button, if successful
    • On the top right corner, show "logout" button. on clicking the button, the user is logged out
    • if correct and email validated, then return a session cookie
      • session cookie
      • we could either manage sessions in the database or using JWT (the latter option is probably simpler)
      • preferred, because simpler: JWT
      • expiry time should be rather short for a financial product, maybe 30 minutes

Note

• The Login flow is simple, with no account management. Basic login and logout, not password change.

  Standard secure Login/Signup flow

Due to GDPR we need to use secure practices that do not expose whether an email address is in our system.

General principles

• all passwords are allowed, only requirement is minimum length, e.g., 8 or 10
  • no other requirements (particularly no password rules like uppercase, lowercase, etc)**
  • (for a low priority feature we will implement later, we will check in the backend whether the password is common or has been pwned)
• passwords and emails are always normalized in backend (both for login and signup)
  • password: trim whitespace at beginning and end
  • email: trim whitespace at beginning and end, make everything lowercase
• passwords use a password hashing algorithm, the hashed passwords is a field of the user table in the database
  • e.g., bcrypt

Lo-fi wireframes

[prayagd]

@ebma @vadaynujra @TorstenStueber @annatekl Have kept the login flow simple, just basic login and logout. Do we also need account management as in Change Password?

[prayagd]

Hey team! Please add your planning poker estimate with Zenhub @b-yap @bogdanS98 @ebma @gianfra-t @TorstenStueber

[ebma]

Just to clarify

The Login flow is simple, with no account management. Basic login and logout, not password change.

'no account management' just means that editing the account data (eg. changing the password) is not in scope for now?

Also

• Show a pop-up with two fields
• "Email" - only emails should be accepted here and no other text
• If email does not exists, show error "Email does not exists, Please sign-up"
• "Password" - only passwords should be accepted in this field
• If password wrong, show error "Incorrect password"
• Show error below the Password field
• Show a "Login" button below these two fields, the button should be enabled only after the two fields are filled and correct

The check for a valid email and password should only happen upon submission. Otherwise, an adversary could just fiddle with the form fields all day to find existing email addresses and passwords. By checking this after the submission we can add spam protection.

[prayagd]

'no account management' just means that editing the account data (eg. changing the password) is not in scope for now?

Yes this is the suggestion from my end, lets see what other stakeholders also say here

The check for a valid email and password should only happen upon submission. Otherwise, an adversary could just fiddle with the form fields all day to find existing email addresses and passwords. By checking this after the submission we can add spam protection.

Valid point, made changes

[TorstenStueber]

on clicking the "Login" button from the pop-up, if successful

@prayagd all that comes after this should be part of another ticket.

Standard secure Login/Signup flow

Due to GDPR we need to use secure practices that do not expose whether an email address is in our system.

General principles

• all passwords are allowed, only requirement is minimum length, e.g., 8 or 10
  • no other requirements (particularly no password rules like uppercase, lowercase, etc)
  • (for a low priority feature we will implement later, we will check in the backend whether the password is common or has been pwned)
• passwords and emails are always normalized in backend (both for login and signup)
  • password: trim whitespace at beginning and end
  • email: trim whitespace at beginning and end, make everything lowercase
• passwords use a password hashing algorithm, the hashed passwords is a field of the user table in the database
  • e.g., bcrypt

Signup

• After signing up, always show a screen that says: we sent you an email, go to your inbox ...
  • if the email already exists in our system, then send an email to the user clarifying that the user account already exists and that they should log in instead
  • (for a feature we will implement later they can also reset their password)
  • if the email does not exist, then it will be a welcome mail with an email validation link (see below)
• the user is not yet logged in after signing up
• email validation
  • the user SQL table has a boolean field emailValidated (or better: a timestamp field emailValidatedAt)
  • contains a link with a unique id (as a query parameter)
  • the link goes to a GET endpoint that returns a 303 to the login page
  • the GET endpoint sets the emailValidated (or emailValidatedAt) field in the user table
  • (for a feature we will implement later, the user will first see a confirmation screen that the validation was successful)
  • the user will not be logged in yet at that point

Login

• if user does not exist or password is incorrect, then just display "wrong email or password"
• if correct, but user not yet signed up, then don't login in the user, but just ask to validate email
  • (for a feature we will implement later, the user will be able to resend the email)
• if correct and email validated, then return a session cookie
• session cookie
  • we could either manage sessions in the database or using JWT (the latter option is probably simpler)
  • preferred, because simpler: JWT
  • expiry time should be rather short for a financial product, maybe 30 minutes

[TorstenStueber]

@prayagd I wrote "for a feature we will implement later" a few times in the above message. Could you already extract this into a new, low priority ticket (could be called "Improve Login/Singup UX")

[TorstenStueber]

Another comment: please don't make signup and login just popups, but make them dedicated pages/paths in the frontend, e.g., /login and /signup. Many good UX reasons for this.

[prayagd]

@TorstenStueber thanks for the comments, update the main description with your suggestions and will create a new ticket for the "for a feature we will implement later"

[TorstenStueber]

@prayagd Thanks, and please link to the new ticket(s) here.

[TorstenStueber]

@prayagd we should move this to icebox.

[TorstenStueber]

This ticket is meant for an obsolete prototype. Closed.