Re: 4D authentication system that allow for stronger security.

[Jody Bevan via 4D_Tech]

Eric:

To get what you have outlined (and much more) you just build your own within 
4D. We had to have a very modern password system in our software since before 
2000.

We have built our new shell with all of the password control in it. The nice 
thing is that the System Administrator gets to set how strict all of these item 
are, and which ones are activated. Therefore this permits a small company that 
decides they do not care about it, to have very simple password system. They 
can then choose to ratchet up the complexity as they need it.

We also implemented that the Administrator can decide if they want to E-Mail 
various alerts. That way you can know that someone is having trouble getting 
logged in, or that their account was locked out after too many attempts. The 
E-Mailing has very many options as well.

All of this information is also saved to logs. Our experience is that system 
Admins ignore most things. When there is trouble, then they can go back into 
the logs and gather all the information they need.

We also let the administrator click on a button that then passes the login 
control to LDAP.

So hopefully you can see that you can roll a very sophisticated system. I did 
not describe all the features by a long shot, but it gives you an idea of what 
you can do with 4D.

Jody Bevan
Argus Productions Inc.
i...@4dshell.com 





> On Sep 6, 2019, at 7:25 AM, Eric Naujock via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Good morning,
>   I did take a look at that article a short while ago. Its an interesting 
> read and they do have a number of interesting security options available. But 
> there is still the fundamental issue that the gateway or login process is one 
> that can be hacked and sometimes quite easily die to the lack of modern 
> protections. When it was released it was pretty good but lately 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.
> 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.)
> 
> Thanks for the feedback.
> 
>> On Sep 6, 2019, at 3:22 AM, Maurice Inzirillo - AJAR 
>>  wrote:
>> 
>> Hi Eric,
>> 
>> Regarding 4D security I recommend to read this special 4D Security Guide to 
>> get a full idea of what 4D offers
>> 
>> https://blog.4d.com/4d-security-guide/ 
>> 
>> 
>> 
>> Best regards,
>> 
>> Maurice Inzirillo
>> -- 
>> AJAR S.A.
>> 
>> https://ch-fr.4d.com 
>> twitter: ajar_info
>> Tél : +41 (0)323422684
>> 
>> 
>> 
>> 
>>> On 5 Sep 2019, at 16:22, Eric Naujock via 4D_Tech <4d_tech@lists.4d.com 
>>> > wrote:
>>> 
>>> Does anyone have a replacement login system for 4D that offers stronger 
>>> authentication security than the current system. Since the current system 
>>> does not enforce password changes, or password complexity it is a pretty 
>>> poor system in the current age. While the encryption is crypt is is still 
>>> brute force attackable as well. There are no failed login lockouts. Nor is 
>>> three the ability to have two factor authentication? Or is this something 
>>> beyond what anyone out there is using. 
>>> 
>>> ---
>>> 
>>> MacCafe
>>> 7860 Central Ave.
>>> Toledo, OH 43617
>>> Phone: (419) 885-1240 X 241
>>> Fax: (419) 517-2063
>>> Eric Naujock  -  ACSA 10.2, 10.3, 10.4 Apple - ACTC 10.5, 10.6, 10.7, 10.8, 
>>> 10.9, 10.10, -ACSP 10.11, 10.12, 10.13
>>> http://www.mac-cafe.com 
>>> email: e r...@mac-cafe.com 
>>> 
>>> AOL IM: erlic
>>> 
>>> 
>>> 
>>> **
>>> 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
>>> **
>> 
> 
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailma

Re: 4D authentication system that allow for stronger security

[Chip Scheide via 4D_Tech]

crypto-coin miners use these cards.
there are boxes which can hold 4 of these cards.
With no consideration for any delay in entering or in the password 
system itself, across 218 trillion combinations...
that is 400,000 attempts/sec * 3600 (1 hour) * 24 (1 day) * 364 (1 
year) = 17,870,400,000,000 attempts/year
this is about 12 years and 2 months. (Tim i think one of our 
calculations is off).

This 12 year time period is not how long it will take to crack a 
specific 4D password, via brute force, it is worse case scenario. It 
assumes that the password to be cracked is the LAST one to be tried. 
There is nothing that says that the very first password tried is not 
correct.  In which case it would take 1/400,000 of a sec.

I think, that we can reasonably say that it should take 6 years 1 month 
to crack a password on average.
Not every password to be cracked will be the first, nor the last.

if the attempt is serious, and worth while, multiple systems can be 
used to reduce this time further, add another 4 GPUs (3 years), or 
another 8 (1.5 years), or 16 (8 months) on average

I, personally, do not know anything about the bcrypt algorithm, nor 
about 4D's implementation (or whatever code they sourced from). The 
algorithm maybe *perfect*, and completely unbreakable within the life 
time of the universe, however, that does not mean that the specific 
implementation does not have flaws, and more then likely there is a 
flaw in the algorithm; if they exist, both of these errors can be used 
to exploit the encrypted data. These exploits will be faster, 
magnitudes faster, then a simple brute force attempt.

While i believe 4D's password implementation has changed over the 
years, some of you may remember there was an exploit available to 
expose all of the users/passwords of a 4D system. I believe this broke 
in v2003. The point is - it existed.

my 2 cents

Chip


On Mon, 9 Sep 2019 14:35:42 -0500, Tim Nevels via 4D_Tech wrote:
> This link talks about using an "8x Nvidia GTX 1080 Hashcat” GPU ― 
> whatever that is ― which can calculate 100,000 bcrypt passwords per 
> second. 
---
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
**

Re: 4D authentication system that allow for stronger security

[Tim Nevels via 4D_Tech]

On Sep 9, 2019, at 2:00 PM, Kirk Brooks wrote:

> More to the point of workstation security after 4
> failed attempts 4D itself enforces a 10 second freeze. Sadly this freeze
> seems to only apply to every 5th attempt - using both17.2 and 17r6.

And you are “sorry” because?

If you think allowing 1 password guess every 2 seconds is not very strong, the 
math for brute force attempt at bcrypt — which is what I understand 4D uses — 
would result in 130,000 lifetimes of years of continuous attempts based on one 
example. Stop reading now if you hate math. 

https://security.stackexchange.com/questions/182111/mathematically-how-long-would-it-take-to-crack-a-bcrypt-password-hash?rq=1

This link talks about using an "8x Nvidia GTX 1080 Hashcat” GPU — whatever that 
is — which can calculate 100,000 bcrypt passwords per second. 

An 8 alphanumeric password of upper and lower case and numbers is 218 trillion 
different possibilities. 

But you can only try 1 of those passwords every 2 seconds, on average. So 30 
per minute * 60 minutes * 24 hours = 43,200 attempts per day. So take the 
218,000,000,000,000 / 43,200 per day / 365 days per year = 13,825,469 years. (I 
love doing math.)

Without the 2 second delay — and checking 13,094 passwords every second — it 
would still take 528 years! 

So I don’t think there is any reason to worry about brute force 4D password 
attacks. :)

Tim

*
Tim Nevels
Innovative Solutions
785-749-3444
timnev...@mac.com
*

**
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
**

Re: 4D authentication system that allow for stronger security.

[Kirk Brooks via 4D_Tech]

Eric,
I got around to looking at the Tech Note Tim Penner put up talking about
this subject. https://kb.4d.com/assetid=78310

I haven't looked at or used the Validate password method but if you are
using 4D users it's useful. First you can pass a hashed (
https://doc.4d.com/4Dv17R5/4D/17-R5/Generate-digest.301-4127707.en.html)
password
as well as plain text. More to the point of workstation security after 4
failed attempts 4D itself enforces a 10 second freeze. Sadly this freeze
seems to only apply to every 5th attempt - using both17.2 and 17r6.

On Thu, Sep 5, 2019 at 7:22 AM Eric Naujock via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> Does anyone have a replacement login system for 4D that offers stronger
> authentication security than the current system. Since the current system
> does not enforce password changes, or password complexity it is a pretty
> poor system in the current age. While the encryption is crypt is is still
> brute force attackable as well. There are no failed login lockouts. Nor is
> three the ability to have two factor authentication? Or is this something
> beyond what anyone out there is using.
>
> ---
>
> MacCafe
> 7860 Central Ave.
> Toledo, OH 43617
> Phone: (419) 885-1240 X 241
> Fax: (419) 517-2063
> Eric Naujock  -  ACSA 10.2, 10.3, 10.4 Apple - ACTC 10.5, 10.6, 10.7,
> 10.8, 10.9, 10.10, -ACSP 10.11, 10.12, 10.13
> http://www.mac-cafe.com
> email: e r...@mac-cafe.com 
> 
> AOL IM: erlic
>
>
>
> **
> 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
> **



-- 
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:4d_tech-unsubscr...@lists.4d.com
**

Re: 4D authentication system that allow for stronger security.

[Tom Benedict via 4D_Tech]

On Sep 6, 2019, at 10:45, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> wrote:
> 
> In the 4D Client “On Startup” method you call the “Current client 
> authentication” command and it returns the “Windows login” value for the 
> currently logged in user. You can do this on the 4D Client machine, you don’t 
> have to execute on server. (The documentation makes it seem much more 
> complicated than it really needs to be.) The command will provide whatever 
> Windows login was used to log in on the machine. So for me it might be 
> “timnevels”. 
> 
> I query the [Users] table for a record with “timnevels” set as the Windows 
> Login and if found I am allowed to connect to the database. If “timnevels" is 
> not found in the [Users] table I you just QUIT 4D and 4D Client is prevented 
> access to the database. It’s really that simple.

Can you also get access privileges from AD? If so, how are they synced to 4D 
Users & Groups? Or maybe they aren’t? If they aren’t, what do you do to manage 
access within the app?

Tom Benedict
**
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
**

Re: 4D authentication system that allow for stronger security.

[Kirk Brooks via 4D_Tech]

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 <
4d_tech@lists.4d.com> 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
.
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:4d_tech-unsubscr...@lists.4d.com
**

Re: 4D authentication system that allow for stronger security.

[Tim Nevels via 4D_Tech]

On Sep 6, 2019, at 06:15, Jörg Knebel via 4D_Tech <4d_tech@lists.4d.com> wrote:

> Arrgh, do you rely believe trusting/relying on an outside “system” is worth 
> even considering?
> 
> Please think again, and than think different and again… 
> 
> Just as a warning,  “Active Directory” and everything coming from Microsoft - 
> use at your customer risk…

Sounds pretty harsh considering 90%+ businesses in the world use Microsoft 
Windows and the built in authentication system, and I’ve not heard of any 
serious concerns. You have to log into the Windows workstation somehow. Most 
use what Windows provides and turn on the password restriction options. 

But as I read posts from so many people, nobody has mentioned 4D’s support 
Single Sign On (SSO) on Windows. I find this to be a great solution for moving 
all authentication out of 4D and just relying on Windows. Enterprise is already 
relying on Windows authentication to allow all the users to log into their 
computers — and manage the passwords — so why not do the same?

Here is the long story for those that don’t know the details of using 4D’s SSO 
authentication. 

I have 1 client that I switched from using my own table based user 
authentication system. Worked out fantastic! Typical setup where you present 
your own login dialog box and require a user to provide a user name and a 
password. Then go query the [Users] table for that user name and validate the 
password they provided with what is stored in the [Users] record. 

If you switch to SSO — and you can only do this in a pure Windows environment — 
you eliminate the need to store any passwords in the 4D system. They are no 
longer needed. All that is needed is a valid Windows login. Just store that in 
the [Users] table. Here is how it works:

First you must run 4D v15 R5 or later version on a Windows Server. Must be 4D 
Server 64bit. Must have the new network layer enabled. And of course you must 
be on a network with Windows authentication — the normal NTLM is fine, but it 
also supports Kerberos. That’s a Windows domain server that does the 
authentication. 

On 4D Server check the “Authentication of user with domain server” checkbox. 
That will turn the system on and make the “Current client authentication” 
command function. 

https://doc.4d.com/4Dv17/4D/17.2/Current-client-authentication.301-4387315.en.html

In the 4D Client “On Startup” method you call the “Current client 
authentication” command and it returns the “Windows login” value for the 
currently logged in user. You can do this on the 4D Client machine, you don’t 
have to execute on server. (The documentation makes it seem much more 
complicated than it really needs to be.) The command will provide whatever 
Windows login was used to log in on the machine. So for me it might be 
“timnevels”. 

I query the [Users] table for a record with “timnevels” set as the Windows 
Login and if found I am allowed to connect to the database. If “timnevels" is 
not found in the [Users] table I you just QUIT 4D and 4D Client is prevented 
access to the database. It’s really that simple.

The beauty of this is that you can TRUST that “Current client authentication” 
will return a valid Windows login that has come from a user authentication to 
the domain server. 

Say “bobjones" brings his laptop from home to work. He wants to log into the 
database as me, “timnevels” so he can do nefarious things. He knows he can 
connect his laptop to the company network and it will get a DHCP IP address. He 
copies over 4D Client to his laptop. He creates a local account on his laptop 
with Windows login “timnevels” and a password he knows. He logs into his laptop 
with that account. He starts 4D Client and attempts to connect to 4D Server. 

When 4D Client calls the “Current client authentication” command, it DOES NOT 
return “timnevels”, it returns “”. That’s because Bob did not authenticate to 
the company’s domain server. The “Current system user” command returns 
“timnevels” on Bob’s machine, but you can’t TRUST that as an authenticated 
Windows login. 

My client can now enforce password restrictions for the Windows login and 4D 
doesn’t have know about it or bother with it. No need to encrypt passwords in 
the 4D data file. When a person quits the company, they simply deactivate his 
Windows login on the AD domain server and then go into 4D and remove the 
person’s [Users] record. 

So what am I missing in using 4D’s SSO feature. Seems great to me. Could not be 
any easier to use.

Tim

*
Tim Nevels
Innovative Solutions
785-749-3444
timnev...@mac.com
*

**
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
**

Re: 4D authentication system that allow for stronger security.

[Eric Naujock via 4D_Tech]

On my 17R3 system the symbols did not work. I tried to do this and they failed 
since I was going to use symbols after forced password changes I have symbols 
in the directory service. I did an enterprise wide password purge since I had 
users who’s passwords were the same as their usernames. I would like it if the 
symbols worked. Unless its just my users (Very possible). But many of them find 
it too hard to use the option to click and use the change password button in 4D.

As for the restore of permissions I have had that wreck my user accounts after 
restoring from a backup my restored user account had no permission access. When 
they restored the membership in various groups disappeared. Most of my groups 
are designer groups where the user accounts are Admin accounts. Very annoying 
to do a restore and have multiple users suddenly unable to login since they had 
no permission in one group that allows them to access the system.

> On Sep 6, 2019, at 11:45 AM, Chip Scheide <4d_o...@pghrepository.org> wrote:
> 
> On Fri, 6 Sep 2019 10:50:30 -0400, Eric Naujock wrote:
>> 
>> 
>>> 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.
> 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 
>> 
> log in as admin
> CHANGE CURRENT USER(2;password)
> export or import
> CHANGE 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:4d_tech-unsubscr...@lists.4d.com

Re: 4D authentication system that allow for stronger security.

[Chip Scheide via 4D_Tech]

On Fri, 6 Sep 2019 10:50:30 -0400, Eric Naujock wrote:
> 
> 
>> 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.
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 
> 
log in as admin
CHANGE CURRENT USER(2;password)
export or import
CHANGE 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:4d_tech-unsubscr...@lists.4d.com
**

Re: 4D authentication system that allow for stronger security.

[Maurice Inzirillo - AJAR via 4D_Tech]

> On 6 Sep 2019, at 16:50, Eric Naujock  wrote:
> 
>>> 
>>> 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. 

4D is using BCrypt algorithm which is slow by design to hash the password. More 
about it :

https://en.wikipedia.org/wiki/Bcrypt

There is a 4D function and a 4D command that can be used to change the current 
user and validate a password :

- Validate password

- CHANGE CURRENT USER

The command execution of both are delayed to prevent flooding (brute force 
attack). As a result, after the 4th call to these commands, it is run only 
after a period of 10 seconds. This delay is throughout the entire work station. 
So brute force is not really a big issue here !


Maurice Inzirillo
-- 
AJAR S.A.

https://ch-fr.4d.com
twitter: ajar_info
Tél : +41 (0)323422684

**
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
**

Re: 4D authentication system that allow for stronger security.

[Eric Naujock via 4D_Tech]

> 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 


> 
>> 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 i

Re: 4D authentication system that allow for stronger security.

[Chip Scheide via 4D_Tech]

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.

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.

> 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.

> 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.

> 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.

> 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.


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.

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
**

Re: 4D authentication system that allow for stronger security.

[Jeffrey Kain via 4D_Tech]

If your organization has AD or LDAP servers already I can't think of a 
drawback...


> On Sep 6, 2019, at 9:33 AM, Tom Benedict via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Is there some news about Active Directory which I’ve missed lately? What 
> weaknesses should I be concerned enough about to devote my efforts at "home 
> brewing" something better?
> 
> Thanks,
> 
> Tom Benedict
> 
>> On Sep 6, 2019, at 06:15, Jörg Knebel via 4D_Tech <4d_tech@lists.4d.com> 
>> wrote:
>> 
>> Jeffrey,
>> 
>>> On 6 Sep 2019, at 01:17 AEST, Jeffrey Kain via 4D_Tech 
>>> <4d_tech@lists.4d.com> wrote:
>>> 
>>> 4D integrates well with Active Directory/LDAP servers. That's probably the 
>>> best way to go, along with some custom code to track failed login attempts
>> 
>> 
>> Arrgh, do you rely believe trusting/relying on an outside “system” is worth 
>> even considering?
>> 
>> Please think again, and than think different and again… 
>> 
>> Just as a warning,  “Active Directory” and everything coming from Microsoft 
>> - use at your customer risk…
>> 
>> 
>> EOD - no further comments!!
>> 
>> … my 2 ¢
>> 
> 
> **
> 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
> **

**
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
**

Re: 4D authentication system that allow for stronger security.

[Tom Benedict via 4D_Tech]

Is there some news about Active Directory which I’ve missed lately? What 
weaknesses should I be concerned enough about to devote my efforts at "home 
brewing" something better?

Thanks,

Tom Benedict

> On Sep 6, 2019, at 06:15, Jörg Knebel via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Jeffrey,
> 
>> On 6 Sep 2019, at 01:17 AEST, Jeffrey Kain via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> 4D integrates well with Active Directory/LDAP servers. That's probably the 
>> best way to go, along with some custom code to track failed login attempts
> 
> 
> Arrgh, do you rely believe trusting/relying on an outside “system” is worth 
> even considering?
> 
> Please think again, and than think different and again… 
> 
> Just as a warning,  “Active Directory” and everything coming from Microsoft - 
> use at your customer risk…
> 
> 
> EOD - no further comments!!
> 
> … my 2 ¢
> 

**
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
**

Re: 4D authentication system that allow for stronger security.

[Eric Naujock via 4D_Tech]

Jong,
Thanks for the feedback. What you have laid out is an interesting concept. I 
like the thought that went into it and obviously its working well for you. I 
will take your feedback and add it to my thought process. My main project only 
has one location but I will have users connecting in from Wakanda, and 4d for 
IOS. That may make things more interesting. But since 80% of the Wakanda 
authentication is all but useless when connecting with a 4D database as the 
primary source, its worth a look. I still cannot figure out how the 
authentication in 4D for IOS works since it only prompts for a username. I 
guess if you can foggier out a persons email address you  can have access to 
their available resources from the IOS gateway? 

Still good food for thought. Hopefully you have depreciated the use of md5 as 
one of you hashes. These days I would not do anything less than SHA256. Bcrypt 
or PBK-DF2 would be even stronger. Plus the Bcrypt or PBK can have salt in the 
password hashes. 

> On Sep 6, 2019, at 2:47 AM, Jörg Knebel via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Eric,
> 
>> On 6 Sep 2019, at 24:22 AEST, Eric Naujock via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> Does anyone have a replacement login system for 4D that offers stronger 
>> authentication security than the current system. Since the current system 
>> does not enforce password changes, or password complexity it is a pretty 
>> poor system in the current age. While the encryption is crypt is is still 
>> brute force attackable as well. There are no failed login lockouts. Nor is 
>> three the ability to have two factor authentication? Or is this something 
>> beyond what anyone out there is using. 
> 
> I roll my own system for more than 25 years now.
> It allows to manage access rights on record level divided by read only and 
> read write.
> 
> Here are some pointers to give you an idea.
> 
> All the information are hold in the data-file and therefore a kind of 
> mirroring of the structure is 
> ( [Tables], [Fields], [Staff], [Passwords], [Branches], [Departments] etc.)
> 
> The passwords are stored as hashes (MD5…SHA512) which makes it a bit harder 
> but not immune against brut force attacks.
> A mandatory change of passwords after a period of time or number of logins 
> can be implemented as well as x-way authentication can be implemented.
> To use this as an addition to the 4D-build-in stuff is also possible, but I 
> don’t see a reason why.
> 
> The access rights for each user are hold in arrays for each user within an 
> organisation like this:
> 
>   READ ONLY
>   NA  AA  UA  DA  BA  FA
> [Table1]  √
> 
> [TableN]  √
> 
>   READ WRITE
>   NA  AA  UA  DA  BA  FA
> [Table1]  √   
> 
> [TableN]  √   
> 
> 
> Legend:
> 
> NANo Access
> AAAuthor Access
> UAUnit Access
> DADepartment Access
> BABranch Access
> FAFull Access
> 
> Every table has the following LongINT “Head Fields” :
> 
> UserIDRefCreated
> UserIDRefModified
> xCorpCreated
> xBranchCreated
> xDepartmentCreated
> xUnitCreated
> 
> Every time a user is accessing a table his rights (arrays see above) are 
> applied.
> 
> Granted to implement this in an existing application will take some doing but 
> it could be worth it.
> 
> For instant if someone within an organisation changes to a different branch 
> but will hold the “same” position, no access rights have to be adjusted and 
> the data from the former branch/department/etc. cannot be accessed any more.
> 
> HTH
> 
> 
> Cheers
> Jörg
> 
> 
> **
> 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
> **

**
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
**

Re: 4D authentication system that allow for stronger security.

[Eric Naujock via 4D_Tech]

Good morning,
I did take a look at that article a short while ago. Its an interesting 
read and they do have a number of interesting security options available. But 
there is still the fundamental issue that the gateway or login process is one 
that can be hacked and sometimes quite easily die to the lack of modern 
protections. When it was released it was pretty good but lately 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.
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.)

Thanks for the feedback.

> On Sep 6, 2019, at 3:22 AM, Maurice Inzirillo - AJAR 
>  wrote:
> 
> Hi Eric,
> 
> Regarding 4D security I recommend to read this special 4D Security Guide to 
> get a full idea of what 4D offers
> 
> https://blog.4d.com/4d-security-guide/ 
> 
> 
> 
> Best regards,
> 
> Maurice Inzirillo
> -- 
> AJAR S.A.
> 
> https://ch-fr.4d.com 
> twitter: ajar_info
> Tél : +41 (0)323422684
> 
> 
> 
> 
>> On 5 Sep 2019, at 16:22, Eric Naujock via 4D_Tech <4d_tech@lists.4d.com 
>> > wrote:
>> 
>> Does anyone have a replacement login system for 4D that offers stronger 
>> authentication security than the current system. Since the current system 
>> does not enforce password changes, or password complexity it is a pretty 
>> poor system in the current age. While the encryption is crypt is is still 
>> brute force attackable as well. There are no failed login lockouts. Nor is 
>> three the ability to have two factor authentication? Or is this something 
>> beyond what anyone out there is using. 
>> 
>> ---
>> 
>> MacCafe
>> 7860 Central Ave.
>> Toledo, OH 43617
>> Phone: (419) 885-1240 X 241
>> Fax: (419) 517-2063
>> Eric Naujock  -  ACSA 10.2, 10.3, 10.4 Apple - ACTC 10.5, 10.6, 10.7, 10.8, 
>> 10.9, 10.10, -ACSP 10.11, 10.12, 10.13
>> http://www.mac-cafe.com 
>> email: e r...@mac-cafe.com 
>> 
>> AOL IM: erlic
>> 
>> 
>> 
>> **
>> 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
>> **
> 

**
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
**

Re: 4D authentication system that allow for stronger security.

[Jörg Knebel via 4D_Tech]

Jeffrey,

> On 6 Sep 2019, at 01:17 AEST, Jeffrey Kain via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> 4D integrates well with Active Directory/LDAP servers. That's probably the 
> best way to go, along with some custom code to track failed login attempts


Arrgh, do you rely believe trusting/relying on an outside “system” is worth 
even considering?

Please think again, and than think different and again… 

Just as a warning,  “Active Directory” and everything coming from Microsoft - 
use at your customer risk…


EOD - no further comments!!

… my 2 ¢


**
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
**

Re: 4D authentication system that allow for stronger security.

[Maurice Inzirillo - AJAR via 4D_Tech]

Hi Eric,

Regarding 4D security I recommend to read this special 4D Security Guide to get 
a full idea of what 4D offers

https://blog.4d.com/4d-security-guide/


Best regards,

Maurice Inzirillo
-- 
AJAR S.A.

https://ch-fr.4d.com
twitter: ajar_info
Tél : +41 (0)323422684




> On 5 Sep 2019, at 16:22, Eric Naujock via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Does anyone have a replacement login system for 4D that offers stronger 
> authentication security than the current system. Since the current system 
> does not enforce password changes, or password complexity it is a pretty poor 
> system in the current age. While the encryption is crypt is is still brute 
> force attackable as well. There are no failed login lockouts. Nor is three 
> the ability to have two factor authentication? Or is this something beyond 
> what anyone out there is using. 
> 
> ---
> 
> MacCafe
> 7860 Central Ave.
> Toledo, OH 43617
> Phone: (419) 885-1240 X 241
> Fax: (419) 517-2063
> Eric Naujock  -  ACSA 10.2, 10.3, 10.4 Apple - ACTC 10.5, 10.6, 10.7, 10.8, 
> 10.9, 10.10, -ACSP 10.11, 10.12, 10.13
> http://www.mac-cafe.com
> email: e r...@mac-cafe.com 
> 
> AOL IM: erlic
> 
> 
> 
> **
> 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
> **

**
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
**

Re: 4D authentication system that allow for stronger security.

[Jörg Knebel via 4D_Tech]

Eric,

> On 6 Sep 2019, at 24:22 AEST, Eric Naujock via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Does anyone have a replacement login system for 4D that offers stronger 
> authentication security than the current system. Since the current system 
> does not enforce password changes, or password complexity it is a pretty poor 
> system in the current age. While the encryption is crypt is is still brute 
> force attackable as well. There are no failed login lockouts. Nor is three 
> the ability to have two factor authentication? Or is this something beyond 
> what anyone out there is using. 

I roll my own system for more than 25 years now.
It allows to manage access rights on record level divided by read only and read 
write.

Here are some pointers to give you an idea.

All the information are hold in the data-file and therefore a kind of mirroring 
of the structure is 
( [Tables], [Fields], [Staff], [Passwords], [Branches], [Departments] etc.)

The passwords are stored as hashes (MD5…SHA512) which makes it a bit harder but 
not immune against brut force attacks.
A mandatory change of passwords after a period of time or number of logins can 
be implemented as well as x-way authentication can be implemented.
To use this as an addition to the 4D-build-in stuff is also possible, but I 
don’t see a reason why.

The access rights for each user are hold in arrays for each user within an 
organisation like this:

READ ONLY
NA  AA  UA  DA  BA  FA
[Table1]√

[TableN]√

READ WRITE
NA  AA  UA  DA  BA  FA
[Table1]√   

[TableN]√   


Legend:

NA  No Access
AA  Author Access
UA  Unit Access
DA  Department Access
BA  Branch Access
FA  Full Access

Every table has the following LongINT “Head Fields” :

UserIDRefCreated
UserIDRefModified
xCorpCreated
xBranchCreated
xDepartmentCreated
xUnitCreated

Every time a user is accessing a table his rights (arrays see above) are 
applied.

Granted to implement this in an existing application will take some doing but 
it could be worth it.

For instant if someone within an organisation changes to a different branch but 
will hold the “same” position, no access rights have to be adjusted and the 
data from the former branch/department/etc. cannot be accessed any more.

HTH


Cheers
Jörg


**
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
**

Re: 4D authentication system that allow for stronger security.

[Jeffrey Kain via 4D_Tech]

4D integrates well with Active Directory/LDAP servers. That's probably the best 
way to go, along with some custom code to track failed login attempts

> On Sep 5, 2019, at 10:22 AM, Eric Naujock via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Does anyone have a replacement login system for 4D that offers stronger 
> authentication security than the current system. Since the current system 
> does not enforce password changes, or password complexity it is a pretty poor 
> system in the current age. While the encryption is crypt is is still brute 
> force attackable as well. There are no failed login lockouts. Nor is three 
> the ability to have two factor authentication? Or is this something beyond 
> what anyone out there is using. 

**
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
**

Re: 4D authentication system that allow for stronger security.

[Paul Lovejoy via 4D_Tech]

You’d have to roll your own. 

Paul 

> On 5 Sep 2019, at 16:22, Eric Naujock via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Does anyone have a replacement login system for 4D that offers stronger 
> authentication security than the current system. Since the current system 
> does not enforce password changes, or password complexity it is a pretty poor 
> system in the current age. While the encryption is crypt is is still brute 
> force attackable as well. There are no failed login lockouts. Nor is three 
> the ability to have two factor authentication? Or is this something beyond 
> what anyone out there is using. 
> 
> ---
> 
> MacCafe
> 7860 Central Ave.
> Toledo, OH 43617
> Phone: (419) 885-1240 X 241
> Fax: (419) 517-2063
> Eric Naujock  -  ACSA 10.2, 10.3, 10.4 Apple - ACTC 10.5, 10.6, 10.7, 10.8, 
> 10.9, 10.10, -ACSP 10.11, 10.12, 10.13
> http://www.mac-cafe.com
> email: e r...@mac-cafe.com 
> 
> AOL IM: erlic
> 
> 
> 
> **
> 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
> **
**
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
**

Re: 4D authentication system that allow for stronger security.

[Narinder Chandi via 4D_Tech]

Eric,

Interesting question... 2FA you could roll your own on top of Twilio's APIs 
perhaps, or use an API driven service like Authy (which implements the Twilio 
piece for you) or AWS Cognito. I did a AWS Cognito integration last year 
building it as a PHP authentication microservice. Would make for a nice 
challenge as a 4D integration project...

Regards,
 
Narinder Chandi,
ToolBox Systems Ltd.
-- 

-Original Message-
From: 4D_Tech <4d_tech-boun...@lists.4d.com> on behalf of 4D Tech Mailing List 
<4d_tech@lists.4d.com>
Reply-To: 4D Tech Mailing List <4d_tech@lists.4d.com>
Date: Thursday, 5 September 2019 at 15:22
To: 4D Tech Mailing List <4d_tech@lists.4d.com>
Cc: Eric Naujock 
Subject: 4D authentication system that allow for stronger security.

Does anyone have a replacement login system for 4D that offers stronger 
authentication security than the current system. Since the current system does 
not enforce password changes, or password complexity it is a pretty poor system 
in the current age. While the encryption is crypt is is still brute force 
attackable as well. There are no failed login lockouts. Nor is three the 
ability to have two factor authentication? Or is this something beyond what 
anyone out there is using. 

---

MacCafe
7860 Central Ave.
Toledo, OH 43617
Phone: (419) 885-1240 X 241
Fax: (419) 517-2063
Eric Naujock  -  ACSA 10.2, 10.3, 10.4 Apple - ACTC 10.5, 10.6, 10.7, 10.8, 
10.9, 10.10, -ACSP 10.11, 10.12, 10.13
http://www.mac-cafe.com
email: e <mailto:e...@mac-cafe.com>r...@mac-cafe.com 
<mailto:e...@mac-cafe.com>
AOL IM: erlic



**
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
**


**
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
**

4D authentication system that allow for stronger security.

[Eric Naujock via 4D_Tech]

Does anyone have a replacement login system for 4D that offers stronger 
authentication security than the current system. Since the current system does 
not enforce password changes, or password complexity it is a pretty poor system 
in the current age. While the encryption is crypt is is still brute force 
attackable as well. There are no failed login lockouts. Nor is three the 
ability to have two factor authentication? Or is this something beyond what 
anyone out there is using. 

---

MacCafe
7860 Central Ave.
Toledo, OH 43617
Phone: (419) 885-1240 X 241
Fax: (419) 517-2063
Eric Naujock  -  ACSA 10.2, 10.3, 10.4 Apple - ACTC 10.5, 10.6, 10.7, 10.8, 
10.9, 10.10, -ACSP 10.11, 10.12, 10.13
http://www.mac-cafe.com
email: e r...@mac-cafe.com 
AOL IM: erlic



**
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
**