How to protect emails in xf_user in server

[Alvin63]

Not sure if this is the right section but. I wondered if there's a way to protect user email addresses stored within the server? From what I've read, they can't be encrypted because they are regularly fetched. It's the one database breach that gets in the news a lot. (Not the my little site is probably of much interest - but .........it would be nice to know).

 

[ENF]

We've just employed well thought out access strategies to prevent anyone from having direct database access.
Database server is not publicly exposed and sits on a private network that's only accessible from a jump server.

We've deployed a few nodes with disk encryption, but not bothering with database content encryption.
If your database and webserver are on the same host/system, which is pretty common for small sites, you just need to make sure that your access to your host is well secured to prevent direct database access.

There is always a 3rd party risk, there is only zero risk when there is no site operating.

 

[Alvin63]

Thank you. Yes same host/system and currently looking into the best way to secure the whole server access. Currently I'm just protecting (not fully) admin.php and /install. And I wondered if I could do the same (use a zero trust policy) for xf_user. Not sure about that, because it's a file rather than a folder isn't it? Anyway securing the whole thing sounds better. If I can work that out.

 

[ENF]

Thank you. Yes same host/system and currently looking into the best way to secure the whole server access. Currently I'm just protecting (not fully) admin.php and /install. And I wondered if I could do the same (use a zero trust policy) for xf_user. Not sure about that, because it's a file rather than a folder isn't it? Anyway securing the whole thing sounds better. If I can work that out.

The correct terminology is that xf_user is a table inside the xenForo database.

There is a datafile on your server called ibdata1 and this is the location where your xenForo database and its contents are stored. The actual data, indexes, metadata and other components are kept in this file.

 

[Kirby]

There is a datafile on your server called ibdata1 and this is the location where your xenForo database and its contents are stored. The actual data, indexes, metadata and other components are kept in this file.

This is only the case if innodb_file_per_table was 0 when the table was created; by default (and strongly recommended, the setting us even deprecated since MariaDB 10.11) this is 1 so every table has its own data and index files.

 

[MySiteGuy]

The correct terminology is that xf_user is a table inside the xenForo database.

There is a datafile on your server called ibdata1 and this is the location where your xenForo database and its contents are stored. The actual data, indexes, metadata and other components are kept in this file.

MySQL/MariaDB hasn't stored databases in ibdata1 for many years, with file_per_table=on being the default. Innodb databases are stored in sub-directories, and each table with data and indexes is stored in individual .ibd files.

ibdata1 is used now solely for remaining metadata and buffers.

(Oops, Kirby beat my response by about 30 seconds!)

 

[Alvin63]

Well that nearly lost me but thank you! So - in fully protecting my server files - does that mean I'm still not protecting the database itself?

The plan at the moment is:

Cloudflare Zero Trust set up for admin.php and /install
Cloudflare IP's whitelisted in IP Manager
My IP (have just gone for a dedicated VPN IP - trying it out) whitelisted in IP Manager

With the idea that only Cloudflare IP's can access the server and anything other than my IP triggers an authentication request for admin.php and /install.

But will that protect all the files in the server? And the database? Or should I also set up zero trust for other files (or the whole of public_hmtl? Is that possible). And would that also secure xf_user in the database?

 

[ENF]

ibdata1 is used now solely for remaining metadata and buffers.

ibdata1 is used now solely for remaining metadata and buffers.

Yep, I realized what I wrote and came back to correct myself. Thanks for catching that.

But will that protect all the files in the server? And the database? Or should I also set up zero trust for other files (or the whole of public_hmtl? Is that possible). And would that also secure xf_user in the database?

Your database storage won't be anywhere near your public_html folders where your site resides. (Surely, I hope it's not...)
Access to the physical database storage would require a OS level account the right privilege settings to access it.

The database server also has it's own authentication (what you put in your XF config.php). And hopefully, that database isn't exposed to the open internet. Whatever you can do to just put a layer of protection over the access to your root site files is probably good enough.

 

[Alvin63]

Thanks. I'm actually curious now. Having just recently had my email address stolen from a large company's database! So the file xf_user doesn't actually contain the list of plain text emails? They're in the database. And the xf_user is there for just allowing them to be fetched - is that right?

And it's server security that's responsible for the database, not anything I do with my security?

 

[ENF]

Thanks. I'm actually curious now. Having just recently had my email address stolen from a large company's database! So the file xf_user doesn't actually contain the list of plain text emails? They're in the database. And the xf_user is there for just allowing them to be fetched - is that right?

And it's server security that's responsible for the database, not anything I do with my security?

No, the xf_user table contains the member's email addresses. As mentioned, the xf_user table is inside the database. (the database consists of tables, which have fields that organize how the data is stored)

(extract from the fields contained in the xf_user table in a production XF database, just like your site)


And yes, your server operator should be responsible for basic security. If you're not on a VPS, but a managed/shared host, then the operator should be responsible for the overall operation of that service.

 

[Alvin63]

So nothing I can do can "increase" database security then by the sound of it.

 

[dunowat]

So nothing I can do can "increase" database security then by the sound of it.

He actually offered a lot of options.

1. Separate DB Server
2. DB w/o Public IP
3. Isolated Network

The application needs to read the DB so its a required function. Another alternative, is to suggest your users create a separate email account and lock it down to a specific email provider. You can do so much to protect data that needs to be used. You can change the SOP and have the user use an email anonymizer service.

 

[ENF]

He actually offered a lot of options.

1. Separate DB Server
2. DB w/o Public IP
3. Isolated Network

The application needs to read the DB so its a required function. Another alternative, is to suggest your users create a separate email account and lock it down to a specific email provider. You can do so much to protect data that needs to be used. You can change the SOP and have the user use an email anonymizer service.

I think this guy is using a managed hosting solution, which means he doesn't have any control over where the database is stored or how it's operated at the OS and DB (DBA) layers.