> On Sep 6, 2019, at 10:19 AM, Chip Scheide <4d_o...@pghrepository.org> 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. > > 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> > >> 4. No account lockouts for fail authentication attempts. An attacker >> can just continuously try usernames and passwords indefinitely. > the only workaround is to have to write your own login dialog. > I do not know if this is viable for iOS or web based access. Yep, That is a definite roll your own. But if you want to be seriously considered in this day and age with a security focused department you best have this as an option. > >> 5. The AD options require that you serve from a windows server bound >> to and AD system. You cannot use this if you have Mac clients or a >> Apple server. > As far as I am aware, this is not true. > Mac can be (and we have some which are) part of the enterprise AD. The Mac can and has been able to bind with AD since OS-X. Though not well until about 10.4.7. But you cannot use the AD authentication tools in 4D from a Mac server. I have recently tried. Yes, the Mac was bound to the AD system and the workstation I tested with was a Windows machine bound to the same AD. Right now for testing I only log the presumed authentication since that system still requires custom authentication code to use the username passed in the 4D system. > >> 6. No ability to define password difficulty or force password changes >> periodically. (I know that need to change passwords regularly has >> been debunked but most govt. best practice documents still believe >> that’s the way to go.) > again - tying into an augmented user system allows this, and is not > difficult to manage. Yep. That’s an augmented solution. But not every project has time to create a new custom augmented solution for each client and their needs. The 4D system is 19 years old with no updates or considerations. Time to look at that again. > > > In summary, while I do not do all of the above, I do 'augment' the 4D > user system. > It seems to me that most anyone using a4D system with a user login > needs to augment it for their own needs; > where is the user located, their phone number, email address etc.... > adding most of the above additional security options is not hard. > > I will admit that the no attempt limit could be problematic, and I have > not tried to resolve that issue, but otherwise I believe that all of > the above mentioned issue can be simple resolved. > > Could 4D implement some (or all) of these things - sure. I do have an augmented directory that I use to hold those extended variables. Not a problem since the database existed prior to the 4d Authentication system. It was created in 1986. It even had the old account password stored in cleartext until I found them and removed those fields. The good thing is we can now encrypt tables in 4D. This way password advice tables and [Employee]/[User] type tables can also be encrypted in 4D. I am not saying your points are not valid. I just with 4D corporate would look at addressing the serious deficiently. It may sound like Im just gripping but really what is needed is a better solution/option. I would expect anyone who is doing 4D in a medical/legal/financial environment probably would have to have a roll your own or you would be at risk of serious liabilities due to laws and regulations about protecting that data. > > Chip > > --------------- > 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
