Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 262 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
Encrypt/decrypt a table
RockAndRoll
Member Posts: 14
Hi all
Am about to make a feature which I (despite my many years with NAV) have not tried before.
Want to encrypt all fields on the fly when entering data in a special table and with a form being able to read decrypted information.
Have no idea where to begin - how to do?
It has to be done in a NAV 2009 Classic, but when talking table there is presumeably no difference.
Thanks in advance.
Am about to make a feature which I (despite my many years with NAV) have not tried before.
Want to encrypt all fields on the fly when entering data in a special table and with a form being able to read decrypted information.
Have no idea where to begin - how to do?
It has to be done in a NAV 2009 Classic, but when talking table there is presumeably no difference.
Thanks in advance.
0
Best Answer
-
Options
AK
Member Posts: 226
What kind of fields do you want to be encrypted? If Text/code only, you could do something simple like parsing each character and add the position of the character to its ASCII value. So for example, if the fifth character is an "a" (ASCII code 97), you add 5 and get ASCII code 102, which is an "f". Keep in mind that the values have to stay in the range between 32 and 127, so your algorithm has to take care of that.
Depending on what kind of intrusion you're expecting this might not be enough, but the internet is full of better encryption mechanisms.
If you have to encrypt other fields like date or time, all you can do is calculate different dates and times so the ones visible when looking into the table are readable but incorrect. Same for option fields, which are internally just an integer.
It might be better to use are temporary table in the form the decrypted records are displayed in. Otherwise you might cause a lot of load and possibly table locks, especially if you encrypt key fields.5
Answers
Just bear in mind that the field will no longer be searcheable. Users will not be able use any filters, and the code will only be able to use search for exact value - if you add the encryption in all the places where system does SETRANE on the field. Range filters, prev/next values - all of this will become impossible,
Dynamics NAV, MS SQL Server, Wherescape RED;
PRINCE2 Practitioner - License GR657010572SG
GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
Was indeed aware of where to place the en-/decrypt and also which features will be missing.
It is the encryption/decryption itself I am looking for - what to use and how. Have never had to use this before.
You would probably need to find a 3rd party dll which does the encryption/decryption - if you are after 'a proper' encryption. The catch here is that NAV is quite limited when it comes to the data it can exchange with external dlls
Dynamics NAV, MS SQL Server, Wherescape RED;
PRINCE2 Practitioner - License GR657010572SG
GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
Depending on what kind of intrusion you're expecting this might not be enough, but the internet is full of better encryption mechanisms.
If you have to encrypt other fields like date or time, all you can do is calculate different dates and times so the ones visible when looking into the table are readable but incorrect. Same for option fields, which are internally just an integer.
It might be better to use are temporary table in the form the decrypted records are displayed in. Otherwise you might cause a lot of load and possibly table locks, especially if you encrypt key fields.
Will follow your idea. It is not for possible intrusions, only for some sensible info's not to be readable for all eyes.