- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Field encryption
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2008 03:32 AM
тАО11-19-2008 03:32 AM
Re: Field encryption
2. Idem for printers, db links, etc (I can get even the Sybase sa password with tcptrace !).
3. I hope you are using httpS.
4. if you split the SSN in different parts (e.g. 1 filed containing the even positions and 1 field containing the uneven positions), then it's no longer a SSN and thus doesn't need to be encrypted (thus by pass the requirement of encryption).
5. I wonder what Volker could get out of memory of a process having the decrypted data in memory.
6. Do you print directly to a (secured) printer or do you keep the file on disk (oeps, unsecured) ? Idem cobol workfiles, sort files.
IMO a loss of time (just as most sox stuff)
fwiw
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2008 04:40 AM
тАО11-19-2008 04:40 AM
Re: Field encryption
I would recognize permanent disk storage as the greatest vulnerability in the whole cycle.
The data just sits there for years or decades, and over and over.
Those files get backed up, moved off site.
The disks may be retired and improperly disposed of. Well meaning consultants (myself) may snarf a copy to analyze (performance) patterns and while not interested in the data themselves, move it out of the careful into the careless realm.
Or maybe it is 'just' an RMS convert producing a CONVWORK in a spot you failed to protect (sys$scratch is often sys$login).
VMS tries to help with file protections, High-water marking, delete/erase, init/erase and such. But once a disk, tape or whole storage subsystem is outside of the running environment pretty much anything can be done to it by anyone.
All that suggests to me that encryption of sensitive data in the files is probably a desirable thing to do. Encrypting the whole (virtual) disk is probably the more transparent, easiest, way to accomplish this for the applications.
fwiw,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2008 05:37 AM
тАО11-19-2008 05:37 AM
Re: Field encryption
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2008 07:18 AM
тАО11-19-2008 07:18 AM
Re: Field encryption
I am extremely skeptical of any site that requests the SSN. Even those organizations authorized to request it tend to botch it. (One open WiFi or WEP WiFi or weak WPA PSK can ruin your whole day.)
It's a particularly questionable human identifier value, too, given the folks running the SSN system have made multiple fundamental flaws in its design (eg: no check digit), and the address space is rather limited, and the set of folks that possess such identifiers might not be what you want it to be.
Organization-generated identifiers (company employee numbers, etc) can be a better solution, as can digital certificates and such. Both of these can be part of other security-related protocols, too. DCs are very handy, including for use with https and with VPNs.
And the SSN is a target regardless, and I'd rather not have a target painted on my applications. Which is why I seek to avoid having SSN or other data. Or to one-way hash the data. The less data and the less recoverable the data, the less that can be exposed in a breach.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2008 12:41 PM
тАО11-19-2008 12:41 PM
Re: Field encryption
It is my naive understanding that my SSN is only needed by a 3rd party if they have to report some of my tax activities to the IRS. If this is the case here then yes, enhance the application and use some form of encryption.
Otherwise replace the SSN with an new ID. Again a change in the application but the right one in the long term.
Now how can I get my credit card number encrypted on my card so that no one else can read it...
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2008 01:06 PM
тАО11-19-2008 01:06 PM
Re: Field encryption
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2008 02:05 PM
тАО11-19-2008 02:05 PM
Re: Field encryption
Ok; I'd then head toward public key encryption (PKE) here, and use the hashed values save for when I specifically needed to retrieve and view the cleartext.
The advantage with PKE is its asymmetry; there is a key to encrypt the data and a second and separate key to decrypt the data.
For most purposes here, only the encryption (public) key is "floating" around. For SSN comparisons and for anything else that doesn't need to retrieve the SSN can use the public key to encrypt the provided SSN and can compare the results against the saved SSN.
Only when the cleartext SSN is required does the private key come out to play.
(And use one of the provided PKE crypto libraries. Don't roll your own crypto.)
- « Previous
-
- 1
- 2
- Next »