Re: Fwd: storing and using sensitive data

On 9 August 2021 07:40:54 BST, Rene Veerman <[email protected]> wrote:
>Good morning, all..
>
>upon closer inspection of the couchdb.apache.org docs and the PHP code to
>access it with (https://github.com/skeyby/sag),
>i've found that i can indeed
>(A) shield couchdb from the outside world by allowing only LAN ip-address
>access to it
>(B) use nginx to provide SSL access (using the free certbot app) to apache2
>serving up SSL for my https://github.com/nicerapp/nicerapp code
>(C) use the couchdb cookie authentication scheme[1]&[2] to let my
>nicerapp/boot.php provide hash-login based access to couchdb and the rest
>of my CMS, by "relaying" the appropriate hashed couchdb login cookie
>nicerapp/boot.php uses https://github.com/gbirke/rememberme and the
>fore-mentioned Sag library to prevent plaintext passwords (to the db) from
>needing
>to be used more than once per session, with the session length being
>variable in both php and couchdb, or needing to store any plaintext
>password anywhere.
>(D) encrypting all sensitive user data with the 'derived_key' from the
>user's account record in couchdb
>
>[1] see https://docs.couchdb.org/en/stable/intro/security.html and the docs
>for 'public_fields', 'require_valid_user', 'secret' and 'timeout' at
>https://docs.couchdb.org/en/stable/config/auth.html#config-couch-httpd-auth
>[2] https://github.com/skeyby/sag/blob/master/src/Sag.php public function
>login
>
>i'll be sure to read all docs provided at
>https://cheatsheetseries.owasp.org/ as well, and integrate them into my
>code.
>for milestone-1 that's still fairly easy to do, because there isn't a whole
>lot of db-access code to it.
>
>milestone-1 for my https://github.com/nicerapp/nicerapp MIT-licensed (
>https://opensource.org/licenses/MIT) CMS will include :
>- very fast bootup time (a fiber internet connection for your server is
>advised in case you'll be using HD or 4K backgrounds instead of initially
>using tiled backgrounds)
>- page loading without white-blanking-screen page refreshes
>- tiled, photo, and youtube video background support (although video
>backgrounds are currently disabled on my https://nicer.app demo site, by
>youtube.com, which i intend to rectify by contacting their support
>department about it this week)
>- server-operator ("customer") CSS loading and DIV loading for the main
>template
>- an very easy-to-use (and documented) apps plugin structure plus URL
>translation
>- users and groups, with access permissions checked by the nicerapp PHP
>code on the server
>- blogging features with tinymce.moxiecode.com as the rich text editor
>- nested-folders photo-album uploads (using the sturdy plupload component,
>and the jstree component to display the sub-folders)
>- an mp3 music player that can translate a whole folder with mp3 files into
>a pretty representation of an artist's works
>- basic IMAP webmail functionality, with full ingoing and outgoing HTML
>support and many fonts to choose from (courtesy of fonts.google.com)
>- a visual theme editor for the site, all apps, and all pages.
>
>milestone-2 will include :
>- webmail attachment handling, fire-and-forget server-based webmail
>synchronization into the much faster couchdb encrypted storage of emails
>(and their attachments on the server disk), and POP mail server support
>- instant messaging support (for dating sites and social media sites)
>- additional social media features (although i dont want to make an exact
>facebook clone, like i didn't want to make an exact gmail clone)
>- (possibly!) forum features
>- (possibly!) web-commerce features (using adyen, most likely)
>
>i didn't write all this as just an ad for my software.
>i wrote it so you all can think of what features *you'd* like to see in my
>CMS, and inform me about that on this mailing list or in a private email..
>
>i thank you for all the help you've provided to make nicerapp more secure,
>and lastly, i'll have you know that milestone-1 will be finished in
>probably no more than a month from now, 2 months tops.
>
>have a nice day, everyone :)
>
>On Sun, Aug 8, 2021 at 11:54 PM Pascal Schorde <[email protected]>
>wrote:
>
>> a good starting point to read up is https://cheatsheetseries.owasp.org/
>>
>> Am So., 8. Aug. 2021 um 22:29 Uhr schrieb Ashley Sheridan
>> <[email protected]>:
>> >
>> >
>> > On 08/08/2021 17:56, Rene Veerman wrote:
>> >
>> > darn, i spoke too soon.
>> >
>> > the rememberme plugin may store only a hashed cookie value for the
>> password,
>> > but no matter how, every time a new session is started, i need the
>> plaintext password to establish connections to the database.
>> > that's whether i use the db cookie auth tech or not.
>> >
>> > so i'm basically looking for a more secure way to store a plaintext
>> password than storing it on disk with chmod 770 and chown rene:www-data...
>> >
>> > On Sun, Aug 8, 2021 at 6:26 PM Rene Veerman <
>> [email protected]> wrote:
>> >>
>> >> nvm!! :) :)
>> >>
>> >> my db (couchdb.apache.org) supports cookie authentication, which is
>> like the rememberme PHP plugin, just another hash value transmitted! :)
>> >>
>> >> looks like i have an actually secure setup for my
>> https://github.com/nicerapp/nicerapp by tomorrow morning :D
>> >>
>> >> On Sun, Aug 8, 2021 at 6:13 PM Rene Veerman <
>> [email protected]> wrote:
>> >>>
>> >>> well, i ran into a major snag.
>> >>> https://github.com/gbirke/rememberme doesn't store plaintext
>> passwords, but i do need a plaintext password to gain access to the
>> database that i'm using.
>> >>> it's a real chicken-and-egg problem i'm afraid.
>> >>>
>> >>> i suppose i could store the plaintext password in a file on the server
>> which i'd read into / store in $_SESSION once a user has succesfully logged
>> in by providing the username and password, or when the user is logged in
>> with a rememberme cookie, which would give me only the username to get to a
>> username->plaintext password file protected with chmod 770 and chown
>> rene:www-data...
>> >>> but i have serious reservations about security when using a scheme
>> like this. ubuntu security holes in apache2 and/or PHP happen just about
>> every 2 years, when the ubuntu.com guys focus on making a new major
>> release, and i since i'm storing more than just theme settings (IMAP
>> credentials and passwords for my webmail app), i'm hoping someone here can
>> point me to a more secure solution..
>> >>>
>> >>> On Fri, Aug 6, 2021 at 9:52 PM Ashley Sheridan <
>> [email protected]> wrote:
>> >>>>
>> >>>>
>> >>>> On 06/08/2021 16:42, Rene Veerman wrote:
>> >>>>
>> >>>> Rene Veerman 5864 Original Poster
>> >>>> 9 min
>> >>>> eh, on windows 10, my username and password *are* filled in by
>> autofill.
>> >>>>
>> >>>> but on my development machine, a kubuntu installation, it does not.
>> >>>>
>> >>>> i hope this is of help to google support..
>> >>>> Rene Veerman 5864 Original Poster
>> >>>> 4 sec
>> >>>> nvm! fixed by following the advice listed at
>> https://askubuntu.com/a/1185476 :)
>> >>>>
>> >>>> ---------- Forwarded message ---------
>> >>>> From: Rene Veerman <[email protected]>
>> >>>> Date: Fri, Aug 6, 2021 at 1:05 PM
>> >>>> Subject: Fwd: storing and using sensitive data
>> >>>> To: PHP General <[email protected]>
>> >>>>
>> >>>>
>> >>>> FYI :
>> >>>> i've read
>> https://stackoverflow.com/questions/1354999/keep-me-logged-in-the-best-approach
>> which explains a lot of the pitfalls involved,
>> >>>> then i went searching for a library that does this for you, and found
>> https://github.com/gbirke/rememberme which appears to work great right of
>> the box.
>> >>>>
>> >>>> i'm now stuck at the autofill functionality.
>> >>>> my site https://nicer.app, with the login button at the top-left of
>> the pages, the middle icon on the right-side of the date-time indicator,
>> >>>> just won't autofill at all, other than offering a multitude of
>> previously used usernames, but i can't for the love of anything get it to
>> autofill the password field.
>> >>>>
>> >>>> this is the same for <input type="password" id="password"
>> name="password"> and <input type="password" id="current-password"
>> name="current-password">
>> >>>>
>> >>>> i could really use some help with that..
>> >>>>
>> >>>> ---------- Forwarded message ---------
>> >>>> From: Rene Veerman <[email protected]>
>> >>>> Date: Thu, Aug 5, 2021 at 6:30 PM
>> >>>> Subject: storing and using sensitive data
>> >>>> To: PHP General <[email protected]>
>> >>>>
>> >>>>
>> >>>> Hi.
>> >>>>
>> >>>> I'm building a webmail module for my MIT-licensed
>> https://github.com/nicerapp/nicerapp websites platform (CMS and more, see
>> https://nicer.app for a demo).
>> >>>>
>> >>>> I don't want to store end-user's email connection settings in plain
>> text on my server.
>> >>>>
>> >>>> I've read all of https://github.com/defuse/php-encryption,
>> understand most of it, but wonder if I can just encrypt the data using the
>> end-user's password, which gets verified by couchdb and as such is only
>> stored as a hash value in the database.
>> >>>>
>> >>>> Will my SSL connection setup, and the password stored in a cookie in
>> the end-user's browser, keep things safe enough to survive a
>> PHP/apache-based intrusion, which tends to open up every 2 years when the
>> guys at ubuntu.com prepare for a new release..
>> >>>>
>> >>>> With regards,
>> >>>>   Rene Veerman
>> >>>>
>> >>>>
>> >>>> Autofill tends to work based on the name and id of the field in
>> question, and this behaviour varies quite a bit between browsers and
>> operating systems. Have you looked at the `autocomplete` attribute (
>> https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete)
>> for that form element? In theory, you _should_ be able to set that to
>> "current-password" to trigger the autocomplete behaviour. However, this is
>> not a guarantee, it's just an attribute which suggests to the browser to do
>> that, not an instruction that the browser must follow.
>> >>>>
>> >>>> --
>> >>>> Ashley Sheridan
>> >>>> https://www.ashleysheridan.co.uk
>> >
>> > Whatever you do, you cannot store a password in plain text. This is
>> irresponsible, and illegal (because of what it's accessing and what other
>> information you've already said you would plan to hold on your users) in a
>> lot of places.
>> >
>> > Please, read up on encryption and apply it to your application.
>> >
>> > --
>> > Ashley Sheridan
>> > https://www.ashleysheridan.co.uk
>>

Given that it's available to the public then, have you considered accessibility concerns with your front end?