I work in a sketchy financial industry and my boss wants me to set up a a database that stores SSNs, tax IDs, and bank account info. How bad of an idea is this?
My plan was to keep a simple cipher script on a flash drive, and then hash the enciphered numbers client side through a database gui. That way, even if the machines were compromised, it would appear to the attacker that he obtained valid information.
Still, I think the legal implications of a data breach are enormous even though I doubt my boss understands or gives a shit. This seems like a pretty secure solution to me, especially since only 3-4 people will have access to the database, but given the worst case scenario, could I be held liable for a breach?
>>52086319
Why the fuck are you asking /g/? this is well over your head, let someone who knows what they are doing deal with it.
>>>/trash/
>>52086689
The actual programming isn't over my head, I'm just not familiar industry security standards and legal implications of a failure. Besides, right now all of this information is stored on a mail server as outlook attachments that any employee can access remotely, so it's not like I can make the situation any worse. I'm pretty much only concerned about my own potential liability, and I figured their may be some db admins in the finance industry on here.
>>52086319
Use a MySQL/Postgres. There are tons of security features, no need to create your own.
>>52086319
Are you working for a bank? If not, don't store that shit
>>52086319
top kek lad your post is funny.
>simple cipher script on a flash drive
what in the fuck do you mean by this? CIPHER SCRIPT?"?"?"#?"?#?!?!"! IN A FLASH DRIVE_!????
>That way, even if the machines were compromised, it would appear to the attacker that he obtained valid information.
wew lad
>This seems like a pretty secure solution
lol
>especially since only 3-4 people will have access to the database
lolol
>but given the worst case scenario, could I be held liable for a breach?
yes, why would your boss want to have this special database. ask corporate or your IT department to replicate whatever fucking stack they use to store the data of the main databases for your use case, or at least ask them to tell you what they use (hoping they follow ISO 27001)
>>52087102
The problem is none of that really matters if an attacker gains root access to a connected PC and someone leaves a password on their clipboard.
>>52087129
That's what I recommended, but they're already storing the info on contracts in plain sight, it's actually kind of horrifying how careless they are. At least in this case I could set records to be automatically destroyed when they are no longer needed.
>>52087396
>what in the fuck do you mean by this? CIPHER SCRIPT?"?"?"#?"?#?!?!"! IN A FLASH DRIVE_!????
A python script that transforms the numbers into different numbers that are technically valid, but do not match client's identity. It's not in lieu of encrypting client side through a secure application, just an added measure.
>wew lad
>lolol
Alright, then explain how it isn't. That's why I'm asking.
>yes, why would your boss want to have this special database. ask corporate or your IT department to replicate whatever fucking stack they use to store the data of the main databases for your use case, or at least ask them to tell you what they use (hoping they follow ISO 27001)
Because the industry is sketchy as fuck, and the corporate structure is composed of a bunch of independent LLCs housed by umbrella corporations. Technically, I work for an LLC, but the central server belongs to the umbrella corporation.
IT is it's own entity, and it's security is a joke anyway. They use a CRM to transmit sensitive documents, which are then just attached to e-mails and stored on the server out in the open anyway.
>>52087619
you'll have to explain your use case better, because from the OP, i only gathered a shitty solution, db gui, hashing, shitty script.
fuck al of that if you want security, im not murrican so i dont know about SSN, i guess it's a fixed-length series of numbers? then have a key that you'll use for XORing the SSNs. if you wanna go ballistic, have a different key for every person. but then the question is how the fuck you are going to use this. you can figure shit out from there. but then, if that computer holding the DB is gonna be connected to a network, there's a shit load of other considerations and im not gonna bother explaining them here.
>>52087950
I'm not writing an encryption solution myself, so I wouldn't use XOR because I want the numbers to appear valid. The idea is that an attacker wouldn't realize that the they were enciphered by an external script. No valid SSN or account numbers would ever be entered into the DB, but I would still be hashing them into the DB using tools from a 256-bit encryption library
And by gui, I only mean mapping query logic to a form in an application which is used to post information to the third party service we have to manage the debits we take from our clients' account, to pull and display transaction histories from that same service, or to pass information to a document generator which I have already wrote.
>>52088519
How would XOR invalidate them?
>>52088649
It wouldn't preserve the lengths of the numbers
>>52088792
It would.
>>52088519
>I'm not writing an encryption solution myself
xoring bits with a key is hardly "writing" an encryption solution. and dead simple to get the original data if you have the key.
>The idea is that an attacker wouldn't realize that the they were enciphered by an external script.
having XORed data will still give you this, but i really dont see the use of this. somebody already got access to your computer, you are most likely to get pwned in many other ways.
>And by gui, I only mean mapping query logic to a form in an application which is used to post information to the third party service we have to manage the debits we take from our clients' account, to pull and display transaction histories from that same service, or to pass information to a document generator which I have already wrote.
does your 3rd party app take as input the raw SSN? top kek good luck
>>52088941
Oh, well then I'd probably do that in the external script. But honestly, I'm probably just going to leave the information out if there's anyway a breach could fall on my head, even though simply hashing the information into a server-side DB would increase our information security by an order of magnitude.
>>52089406
>>52089461
also, i'd strongly recommend having a separate key for every SSN if you are using XOR. an attacker can figure out the real SSN from a XORed one and easily get the key to "unXOR" the others. anyways, i think you have more shit to worry about than this. the least you can do is not have anything in cleartext. ask your 3rd party what sort of hash or encryption they are using so you can feed a hashed/encrypted SSN to them instead of the raw one.
>>52089406
>xoring bits with a key is hardly "writing" an encryption solution. and dead simple to get the original data if you have the key.
>having XORed data will still give you this,
I didn't think XOR masked a bit pattern in such a way as to preserve the length of a number, but since it is that would be the ideal way to preprocess input.
>i really dont see the use of this. somebody already got access to your computer, you are most likely to get pwned in many other ways.
Because legal liability stems from the clients having their information exposed. Taking down the system will fuck over the company by halting operations, but it won't open them up to legal action.
>does your 3rd party app take as input the raw SSN? top kek good luck
The application I wrote doesn't, and while the ACH service we use doesn't either, it does require account and routing numbers as part of an xml record to register transactions, which I agree is completely ridiculous. Records are queried by transaction ID at least.
>>52089646
Yeah, I just realized that I'd need another program just to generate the keys and some kind of key manager on top of that. The more I think about it, the more it seems like SSNs aren't worth the trouble because they don't add very much utility. I may even just nix all the sensitive info and remove posting functionality from the application.
>>52086319
>sketchy financial industry
I assume this is NA, but regardless the financial industry is heavy regulated currently. Your CTO (your boss) can likely be imprisoned for not properly securing that type of information. Short of that, they're hefty fines also associated with improper handling of that type of information as well.
>>52090053
>financial industry
>regulated
Do you know how many boutique investment banks there are and how little they give a fuck about the SEC?
>>52090642
>boutique investment banks
>no citation
Try not caring about the SEC when your database gets compromised and everyone from the Analyst(s) who created the database to the CTO/board members get massive fines and legal ramifications from multiple class action lawsuits.
Just look what has happened to Target. There are many more examples too. That whole notion of the financial industry not caring about the SEC is a myth. They are so scared they have been hiring MASSIVE amounts of DevOps/Security Analysts who do nothing but make sure their IT departments are compliant with the laws.
>>52090906
A citation for what, boutique investment banks existing? I don't understand how you're trying to make me look stupid. They just made a movie about one called the Wolf of Wall Street if that's citation enough for you.
And the SEC doesn't give a shit about the securities violations of any bank pulling in less than 100 million in revenue per year. The worse they'll do is hand out censures 99% of the time. Data breaches are a different story it's, but most disreputable banks don't understand how serious they can be and do not spend on IT like you think they do.
