Eaglesoft 18 Security:
This was tested with ES 18 RC3 because Eaglesoft 18 is currently in beta.
How does ES Authenticate?
When ES18 is installed, 3 backend database accounts are created: SA, DBA, and PDBA.
All 3 passwords are randomly generated, and each have different levels of access. Though the SA password may go off the License File. (Needs more testing)
These passwords are stored in a binary file called:
C:\Eaglesoft\Data\Eaglesoft.Server.Configuration.data
Patterson Eaglesoft consists of 2 main services to function (actually 3):
“Sybase SQLAnywhere” and the “Patterson Application Server” service.
When the The Patterson Application Server service starts, it reads the Eaglesoft Server Configuration Data File at: C:\Eaglesoft\Data\Eaglesoft.Server.Configuration.data, which then allows it to know all the backend database passwords, when it does this it resets the password for the SA account, if the password has changed, but leaves PDBA and DBA untouched.
This service also checks the database signature to make sure it is from a Patterson Database.
SELECT user_id, "option", setting FROM SYS.SYSOPTION WHERE "option" = 'database_authentication';
Example of returned information:
Company=Patterson Technology Center;
Application=Patterson EagleSoft;
Signature=010fa55157edb8e14d818eb4fe3db41447146f1571g574591ba89b065b5aabdb10bca8923c8b6b14496
Application=Patterson EagleSoft;
Signature=010fa55157edb8e14d818eb4fe3db41447146f1571g574591ba89b065b5aabdb10bca8923c8b6b14496
This signature seems to match data in Eaglesoft.Server.Configuration.data file, because the two seem to go together.
NOW THE SERVER IS READY TO HANDLE CLIENTS!
What happens next?
The Eaglesoft Clients on workstations talk to the "Patterson Application Server" service that is running on the server and get the database credentials through TCP and Ajax calls (partly encrypted).
This allows the Eaglesoft Client to login as DBA or PDBA respectively.
Example of a DSN-Less ConnectString:
DBN=DENTSERV;DSN=DENTAL;UID=PDBA;PWD=vBB(JDvSi1M?p%weic$f-T-SFOMm#UAz
DBN=DENTSERV;DSN=DENTAL;UID=DBA;PWD=CKGHF2L.
Patient, and Provider SSN's seem encrypted.
Example of what is in the database
SSN=*****6789
Encrypted SSN=/KYTzmB7YfkdyN4SqbNM5vPzw2lxbpli5gr1Niv6UXE=
![]()
Passwords in the actual database that Eaglesoft users store are now hashed.
![]()
IS Eaglesoft 17... Not HIPAA Compliant because of the lax security and passwords that are not hashed?????? http://justinshafer.blogspot.com/2016/02/moving-onto-eaglesoft-aka-patterson.html
This doesn't matter, because someone could (in theory) dump the database remotely (after they hacked the wifi), and then use the Eaglesoft software itself to decrypt the database (yes, with a different license installed). I have a good idea that the key is a 64 character key, but you would need to know exactly how the Patterson Services Crypto Service decrypts the password. Once the dump the databases, and have the PDBA Password, they could probably get the SSN's out of the database (I think I could, but only using the actual ES software, after I added the patients table to my own database).
The weak link I see in this overall design is the Patterson Application Server service, and it handing out backend database passwords to people who know how to ask it without some sort of password from an administrator.
Thoughts:
What happens if we only have the Patterson Database files without the file that knows the passwords??? C:\Eaglesoft\Data\Eaglesoft.Server.Configuration.data Lets say someone forgot to back that file up? I suppose I could change the hashes in the database server, reset passwords to a different installation based off the same license file?IS Eaglesoft 17... Not HIPAA Compliant because of the lax security and passwords that are not hashed?????? http://justinshafer.blogspot.com/2016/02/moving-onto-eaglesoft-aka-patterson.html
NOW FOR THE BAD NEWS: WEAK LINKS!
The big weak link I see is someone who is malicious (or obsessive), could use an Eaglesoft 18 client to find the PDBA Password by just hacking the wifi, and launching Eaglesoft.exe, and then use WinHex to find the backend password for another installation, then dump the patient table.
![]()
The last thing they will have to deal with (the third possible weak link) is decrypting the SSN, although they would have the last 4 digits of the SSN which could pose a security risk.
This doesn't matter, because someone could (in theory) dump the database remotely (after they hacked the wifi), and then use the Eaglesoft software itself to decrypt the database (yes, with a different license installed). I have a good idea that the key is a 64 character key, but you would need to know exactly how the Patterson Services Crypto Service decrypts the password. Once the dump the databases, and have the PDBA Password, they could probably get the SSN's out of the database (I think I could, but only using the actual ES software, after I added the patients table to my own database).
The weak link I see in this overall design is the Patterson Application Server service, and it handing out backend database passwords to people who know how to ask it without some sort of password from an administrator.
Solution:
When a new client wants to connect or install, let the office come up with their own database password to initially connect. I believe this is how Dentrix G6.2 is going to work (I hope). You could make it a database passhphrase (scrambled password) instead of a password, or just make it the actual password. Or beef up the Patterson Application Server Service.
#PinkyOut
#PinkyOut