On Fri, 6 Sep 2019 10:50:30 -0400, Eric Naujock wrote: > > >> On Sep 6, 2019, at 10:19 AM, Chip Scheide >> <[email protected]> wrote: >> >> On Fri, 6 Sep 2019 09:25:39 -0400, Eric Naujock via 4D_Tech wrote: >>> as I look closer at it with questions from a state government >>> security person I can see a number of glaring holes that should be >>> filled. These are the biggest ones I see. >>> >>> 1. Passwords are only alphanumeric. >> ?? what else do you want? >> letters, numbers, and any (as far as I have found) other key and/or >> combinations, including [odd to US entry] characters which include >> umlauts(sp?), and other multi-keystroke characters. > > In a good system you should be able to use anything for a password. > Letters, numbers, symbols. Any Valid unicode character should be > available. Especially since 4D is pure unicode since v11. If you only > going to hash the unicode text string then any character should be > valid. But in my testing even common symbols" @#$%” cause the system > to fail. Plus there is a length limit of 15 character for a password. > In my PHP code I can use anything unicode up to 5000+ character long > passwords. Is that insane? Yes, But it also effectively allows for > anything to be a password. unless there is some major change in the password system (v13): I just entered a 24 character password, accepted, and logged in -- no issue I just entered !@#$%^&*() as a password, and logged in -- no issue
I know that other characters such as umlauted letters work in passwords. I did not try to test for max length. so.... for this issue I do not know what you are on about. > >> >> There maybe a maximum length but I have not entered sufficient >> characters to find it. >> >>> 2. No two factor options. >> true - as someone else pointed out adding it possible. > I have kind of looked into this possibility. More work, of course if > somebody were to make a 4D library to do all these things would there > be an interest in doing so? With the new ORDA stuff it may not be a > hard as it used to be. > >> >>> 3. Usernames and password are stored in the Structure file. (Very bad >>> if your revving structure files during continuous developemnt. >> it requires only a small bit of code to save (and encrypt) the user >> group info to a disk file or into the data file, or both. > When you export the user accounts only Admin accounts get exported. > Developer accounts do not. Also to use the user export you have to > logged in as admin. Otherwise the export to blob and import from blob > will fail. I had to wrestle with that for a few weeks. I do have a > script that runs just before the backup process that tries to archive > all usernames and password to a table in the data file. Additionally > I have discovered that when you export users only user accounts and > passwords export. Permissions do not export or import from the export > blob. Talk ab out a bummer to restore the password for my users after > a big upgrade and have the users lose access to resources since the > permissions did not come back with the restore. > https://docs.4d.com/4Dv17R5/4D/17-R5/USERS-TO-BLOB.301-4127460.en.html > <https://docs.4d.com/4Dv17R5/4D/17-R5/USERS-TO-BLOB.301-4127460.en.html> log in as admin CHANGE CURRENT USER(2;password) export or import CHANGE CURRENT USER(<current user>;password) I have not had an issue with user/group permissions when exporting/importing --------------- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
