srssec / srspass-pwa Goto Github PK

Since a license has been added as of LavaMoat/LavaMoat@088fc1b
it now seems safe to use, and would be very useful to integrate upon internal project stability

• minimize bundle size further with more aggressive tree-shaking and removing unncessary imports/pkgs
• brotl compression and other cloudflare optimizations, handled during bundling

Curent is likely sufficient, but in case password starts failing, an easily identifiable user identicon may be useful on the unlock page

• maybe add identicon for m/1337'/0' ( or other) acct
• consider any other options, technically #4 should aid in authentication, in that they will fail to decrypt, if the seed phrase is changed. A warning can be emitted regarding this, indicating corruption of some sort.

Add toggle for saving accounts information in localStorage (encrypted). This should become the user default, as there's performance gains to be had, by simply requiring the genPass once, and then using a key from the seed phrase for decryptions ops.

• add toggle/option
• implement in stores code. Initial draft is to encrypt with a seed phrase's key, maybe m/1337'/0', AES-GCM the payload, which should include metadata (password length + characters + any other necessary params?) and the password itself. In plaintext, a slice of a hash should be included to allow for "pass compromise" search tool, the hash algo is TBD, but internally am leaning towards BLAKE2b or whatever series of functions would best fit a bloom filter for the password compromise tool.

should cover rudimentary seedBlob localstorage transfer in docs, however, if corruption occurs, a prompt should be given with instructions on backing up the old seedBlob and renaming it, or this should be done internally for the user, and then re-running them through setup, with an alert before all this.

So far, this has not been an issue, but could be with those that screw with their browers, in which case their warranty may be void, or others could have this occur due to browser/storage corruption.

leaning to 20 len w/ alphanumeric + symbols

will likely need a mechanism to ensure 1 of each is used that wont completely kill entropy

research would be useful for building pre-gen lists per URI

Good source as a basis: http://web.archive.org/web/20130907182806/https://defuse.ca/password-policy-hall-of-shame.htm

^

provide a frictionless sync capability for premium users (tbd by the backup phrase). Some initial ideas are:

• requires statefulness of generated passwords, however, the password itself would never be stored, but their supporting parameters... prolly complete params to avoid backwards compat issues, could also set some global/re-use key to save space, e.g. defaultParams key, and then use those if certain params missing, or even globalX, and apply those to any in hte object, until another glob definition.

• the contents at rest should be AES-GCM encrypted, using at the very least, the backup phrase seed, or even another derived key from it, maybe using balloon hashing, in which case we may use the unlock pass seed as well. This should make any cracking, while stored on our servers practically impossible with even the default 12 word backup phrase and a crappy password, let alone with a good password, or moreso 24 words. The latter could safely be stored in public access even... assuming proper encryption, in which case we'll need to take great care of the encryption mechanics. Could use the deterministic IV mechanism based on content to be encrypted.

• Once a premium user logs in with a matching backup phrase + pw we sync those passwords for them, either opt-in or automatically based on some future options

• TBD atm we're going with a single pw/backup phrase combo design... if a pw is compromised, you should create a completely new backup phrase/pw combo, and not re-use the old one, so we don't support changing passwords, as that isn't sufficient from a security perspective upon a compromise.

• update DNS

Once comfortable on flow plus security, remove experimental alpha disclaimer

• offload argon2 computation to a seperate worker, to avoid blocking the main UI thread
• simplify service worker utilization via webpack plugin
• takes uri, login, generator pass, index inputs
• uses uri, login, seed as the salt

blocked by needing stores

• use the seed from localStorage (this flow can be greatly simplified and backed by auth, by utilizing AES-GCM on the encrypted seed, and re-using the generator pass for encrypting the seed and ofc subsequent pass generation... will need to review/revise blueprint)
  addendum to this point, one 256-bit key is derived from "unlock pass" for decrpytion and another 256-bit key is derived for use with Srs Pass derivation

probably a wontfix unless many other users find large issue with it

isolated bug found by one user which shouldnt affect UX too bad and if anything could act as somewhat of a bug turned security feature, by masking words when they're correctly entered, on focus loss.

• gives users the option to opt-in to manual update confirmation

check workbox for this

Issue 2.2 from #23

• check the RNG internally utilized and if it is one considered sufficient for PRNG in crypto use
• consider utilizing other browser built-ins
• consider allowing user input to XOR the generated entropy

seems tabs were inherited from the initial template...

• (grey) Content is sized correctly for the viewport
• (red) Is not configured for a custom splash screenFailures: Manifest does not have a PNG icon of at least 512px.
• (red) Does not provide fallback content when JavaScript is not availableThe page body should render some content if its scripts are not available.
• (red) Manifest doesn't have a maskable icon. A maskable icon ensures that the image fills the entire shape without being letterboxed when installing the app on a device.

Currently 5/8 score on lighthouse for PWA

While at it, also resolve Best Practices and SEO issues keeping them from being 100:

BP

• (red) Browser errors were logged to the console

/workbox-3ec4d9f3.js(alpha.srspass.com) | no-response: no-response :: [{"url":"https://alpha.srspass.com/","error":{}}] at Object.handle (https://alpha.srspass.com/workbox-3ec4d9f3.js:1:10120)
-- | --

SEO

• (red) Document does not have a meta description. Meta descriptions may be included in search results to concisely summarize page content. Learn more.

follow this guideline: https://evilmartians.com/chronicles/how-to-favicon-in-2021-six-files-that-fit-most-needs

Important

• enforce allowing only lowercase input in verify mnemonic part... this is apparently a big pain point for users so far, on mobile it auto capitalizes first... ab4c4c6#diff-cdf5b28a79e8b577952a76da20b29922d2a6a22b00a7cc484a5fa55911409148R3

Normal

• must have modal asking if user is new or existing, and send to different page depending on it
• make note on the verify mnemonic page that the user should refresh the page if they didn't save the backup phrase in last step, and READ & FOLLOW THE INSTRUCTIONS CAREFULLY! Could consider more lax UX and just not locking them from going back.
• verify the FULL phrase... multiple times users have only correctly saved 11 of 12 phrases (this was already in over a month prior to this request, at least in prod side: bc40ad9#diff-b73fd971951b4448fedf156cdf3399fcbe53e67f4d9442977e46c1584b513673R47)
  - [ ] OR number the words, to avoid users missing them... however, still not foolproof (could become AND if problems again noted)
  - [ ] dont let user enter anything that matches the backup phrase for their unlock password, make clearer this is user generated pass (reinvestigating this)
  user might use a password from bip39 words, aka not collision resistant, so this may be worse than better
• on prompt 7 user was asking if they are done with the process, make clear they may now continue to the rest of the application c1b766a
• confused by url, maybe mention in tooltip, website name or change url to website? c1b766a

maybe

• look at old modal for inspiration to improve visual acuity of the setup https://github.com/SrsSec/SrsPass-pwa/blob/develop/src/modal/WelcomeModal.svelte
• mixing of nav buttons + verify/confirm etc... may be confusing. Consider hiding them when disabled or reworking it
  - [ ] providing a QR code hover or save as on backup phrase
• prompt/alert regarding nav keys such ash h l enter, maybe identify if pc/keybaord user or non-mobile for this prompt
• some users get confused by disabled nav, might be bad non-obvious disable coloring on device/browser
• autofocus on inputs for users, some users have trouble clicking them ab4c4c6
  - [ ] TAB or some other key to autofocus on current prevalent input on page? Would be useful for pass for key users
  superceded by above autofucs
  - [ ] alert if user is clearly not reading, maybe allow prev on verify, but tell user to make sure they save it... they shouldn't be going back to check
  too invasive
• tell users setup will take 5 mins c1b766a

if pushback or complaints
- [ ] regarding autofocus, as per https://stackoverflow.com/a/57258701 it may affect impaired users, may be useful to add option or choice to disable this somehow upon setup...
minimize choices unless complaints voiced

2020-12-20 priority

• add skip button to verification, based on user review. User's have indicated they would normally not do a step like that, as it feels far too cumbersome. Warn users on the reprecussions of a wrong password, and guide them to a page in the docs or the like, where it explains on testing the backup phrase on another device, to get the same srs pass output. Do it via a confirm, requiring confirmation that user understands reprecussions of skipping... and maybe add localStore variable noting this... or consider adding later backup option via quick-start as backport
• add a counter to note how many more words must be verified, or a table of words numbered 1 - 12 on a table getting crossed out
• consider a step tracker, step 1 of 8 etc..., maybe as a sidebar if not mobile, or just go mobile first and have it in the modal, on header or footer of it... this could cause difficulties when it comes to quick start implementation, as we'd be skipping steps.... so going from step 2 to 8 may seem weird and confuse
• Sidebar would still be very nice

These 2 points are smaller solutions to the ultimate problem we may run into, the ultimate solution may be to allow skipping of the initial setup, except for the master password... to be explained in a seperate issue to be linked back here as it will be a heavier feature

• #30

• add additional advOpt for showing the custom format definitions, or link to docs with it?

• consider popover elements, as replacements for the current tooltips style, for benefit of mobile users... or find some other alternative that makes the tooltips work there, without being as invasive as popovers.

• make instructions more concise, now that docs page is up, and instead see about linking to docs page, with ? hyperlink, where appropriate

• offload store ops to it
• include encryptions where necessary for localStorage ops

focus this initially on the seed phrase and then supplement with saved accounts (supplementation can be part of future milestone, MVP 0.2?)

should be quite simple with webpack + workbox, simply import them and test!

This might lower bundle size and bloat... as right now it imports the kitchen sink and much unused code... and much seems left even after tree shaking, such as asn1, elliptic crypto etc...

the issue may be with sw registration or some workbox plugin load problem. could be a misconfiguration on the eagerness as well

• make PWA work nice on a single load so it can work in offline mode immediately
• confim PWA can be added to homescreen on first load and work fine while offline thereafter, on its first load

Research (Both security implication-wise and end-user), if AES-GCM alone is sufficient as an auth guarantee for the seed phrase (that someone didn't maliciously change the seed phrase):

• implement seed phrase encryption as AES256-GCM on user-end.
  - [ ] maybe add identicon for m/1337'/0' ( or other) acct
  - [ ] consider any other options, technically #4 should aid in authentication, in that they will fail to decrypt, if the seed phrase is changed. A warning can be emitted regarding this, indicating corruption of some sort.

blocked by #3 needing stores implementation first

Ideally using something compatible with webpack out of the box, so that manual maintenance is minimal while security is pretty high, such as:
https://github.com/slackhq/csp-html-webpack-plugin

or have some basic manual http meta definitions.

Put each in their respective categories... direct app imports may make more sense as straight dependencies.

keep a "suckless" version with minimal css, and one for general clientele with a pretty CSS framework

• find a css framework
• apply necessary classes to components, without it breaking suckless version

• setup dist branch
• host app.srspass.com on github, in security review consider if GH or on-prem is more secure and trustable
• proxy to cloudflare

• make webpack output bundles and other parts with hashes
• add procedure for signing built bundles and sig page under srspass.com domain
• publish to ipfs

Would need stateful credentails #4

Research if this would help customer acquisition... Ideally, a user rebuilds all their passwords utilizing SrsPass, and maybe what would make more sense is a script to help change some common accounts instead.

Likewise, research if export to another common pass format, might help decrease any feeling of a potential sunken cost with SrsPass if it doesn't fit them, thereby increasing market penetration.

• implement composable "nav modal"
• create component to output bip39 mnemonic
• abstract the work out to stores/ or stores.js
• create component for taking user generator pass, and encrypting bip39 seed to localStorage
• abstract the work out to stores
• add clear and concise instructions for backup of seed phrase and use of generator pass
• verify user mnemonic
• improve verification by checking words in randomized order, from same component
• abstract the nav modal more by allowing passing of specific stores to be shared amongst the components
• enable import of user's own bip39 seed (maybe in the verify seed phrase portion) (better idea may be to have it the 2nd modal, and allow skipping or if import and valid, to skip other steps!)

can keep most of this in the sessionStorage and offload localStorage ops to 'stores.js'

Possibly leave out the stores abstraction for seperate stores issue, and worry about it then and there

This would be for new users only, because an existing user would have to enter their backup phrase in anyways, however, there's room for imprvoement on this even for existing users, which will be a point

• in regards to existing users, their ux flow could be improved, by skipping the verification portion IF the backup phrase was imported, import could skip to the password page if it's valid.
• The first page, should offer quick-start for new users
• the initial auto generated backup phrase would be utilized, and have to be stored in localStorage, for later user backup
• TBD if it should be erased from localStorage on first backup, and warn the user, OR give the user the option (this option might confuse and scare users, and opt them into a less secure state)
• if quick-start is opted into, we can skip directly to the last password steps of the setup, or even hook the unlock screen, but i think i prefer the first option.

seen on brave

Consider whether this may be a more secure alternative to either node's native crypto module or argon2-browser

See what it would take to make the current argon2 wasm implementation also work with SIMD where available. Rudimentary testing on https://antelle.net/argon2-browser/ shows ~5x speedup

• bundle.css MIME type complaint, but may be limited to hot reload dev or browser?

blocked until end of project

Needs #4

• allow localStore for credentials to be exported, so users can sync it with their other devices or keep it as a backup
• maybe consider some common format, like keepassxc? Although, this could result in losing some useful metadata, so probably not worht it.

Likely 0.2

this can be pretty low priority... as additions of future links is unlikley

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigUint64Array for compat

1.1 ideal

• find and use polyfill or shim for this type on

1. 2 less ideal

• create polyfill

1.3 fallback
downgrade to using uin32array, which all browsers support... would technically increase the probability of certain characters appearing more than others, based on their index, however, should still be negligible enough

2.1 must

• make sure to use a dataview or the like that'll result in consistent endianness, regardless of platform! BigUint64Array is platform specific

2.2 must

• add endinanness specific tests, may be spliced out to another issue