Hi Eric, This is a good discussion and you are making a lot of good points.
On Fri, Sep 6, 2019 at 6:25 AM Eric Naujock via 4D_Tech < [email protected]> wrote: > 1. Passwords are only alphanumeric. > 2. No two factor options. > 3. Usernames and password are stored in the Structure file. (Very bad if > your revving structure files during continuous developemnt. > 4. No account lockouts for fail authentication attempts. An attacker can > just continuously try usernames and passwords indefinitely. > 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. > 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.) > #1 is something 4D should simply fix. Period. But this may be an issue with r3. I don't see it on 17r6. #3 is true by default but easy to change. The rest though - I was trying to think of a desktop application that offers those points and couldn't come up with any. But you are talking about 4D server rather than 4D local or a built app. Gaining access to a server db would require running a 4D client or spoofing one. And you need direct network access because I'm assuming if the data in this db is critical you aren't going to run your server on a public IP. So first you need to crack the network security to even get to the point where you can run your keystroke bot. And you need to know a user name. I have also run my own user auth scheme for twenty or so years. I've used several approaches. I really like the new option 4D offers of SET USER ALIAS <https://doc.4d.com/4Dv17R5/4D/17-R5/SET-USER-ALIAS.301-4276122.en.html>. The scheme here becomes defining a default user with no password and no permissions. On login you start an authorization loop. At this point you totally control the situation and can enforce whatever rules you want. I haven't looked at 2FA solutions like Authenticator or others but one could probably to found to work. At the very least you can insert a delay between authorizations that come back false. DELAY PROCESS for a couple of seconds coupled with a max number of fails. If the user succeeds you assign them to an authenticated use account and start a session process. If they fail you simply kick them out. So now the question becomes is it possible to break out of this process? In a compiled db I doubt it. But let's say they are able to break out of the authorization loop without getting a valid password. That is what 0day exploits are all about. Where would you go with no permissions? 4D doesn't have a CLI. The only menu options would be the ones you provide which should be none. The best hope for a compromise would be to invoke EXECUTE with a payload of a "PROCESS 4D TAGS (with malicious code)". And if you pass the name and password to a separate method for verification, instead of setting a variable in the form process, the targets for spoofing are small. There is an opportunity for code injection via the user name field if the lookup is using ORDA and you are sloppy about filtering the input. So don't use ORDA for that. Use a classic query. And limit the length of the name string to something reasonable like 30 chars or so. More is just asking for trouble, though the user doesn't need to know that. I would not say this type of attack is impossible. But it would require a deep understanding of 4D and the structure of the database. And compiling greatly improves security. Interpreted mode is really development mode. There is some security but it's pretty easy to circumvent if you have experience and dev access. Not so once it's compiled. You could set up a test database using these principles in a couple of hours for your network folks to bang on and attempt to break. It doesn't need to have anything real in it to test the login stuff. -- Kirk Brooks San Francisco, CA ======================= What can be said, can be said clearly, and what you can’t say, you should shut up about *Wittgenstein and the Computer * ********************************************************************** 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] **********************************************************************
