claudetools/clients/glaztech/reports/2026-06-05-tom-reply-draft.md

Draft reply to Tom (calm/partnership tone, 2026-06-05)

Channel: reply to Tom's email/message (the one where he listed what he's already done). Tone: affirm his direction strongly; ask rather than assert; remind rather than demand. Context: Tom independently encrypted PAN/CVV/passwords, is building separate web-only DBs on 0.55 with a dedicated low-priv web login, and converting inline SQL to stored procs. This is the architectural fix we scoped — ACG's role shifts to validate/align + own the backend infra.

---

Subject: Re: Glaztech site — we're in this with you

Hi Tom,

This is great to read — honestly, it's exactly the direction we were hoping for, and you're already further down it than I expected. Splitting the website onto its own databases, getting cc_file off that surface entirely, and giving the site its own limited "web" login instead of your personal one — that's the heart of the whole thing. The stored-proc cleanup and the longer-term move to everything going through the *.dll library layer is the right endgame too. You're solving the hard part at the source, which is better than anything we could bolt on from outside.

A few things I wanted to ask about rather than assume, just so we stay aligned:

• On the card data — the encrypted PAN column is a solid step. Out of curiosity, where does the decryption key live relative to that database? The thing that makes column encryption really pay off is the key sitting somewhere the web login can't reach, so a compromise of the site doesn't hand over both.
• One heads-up worth flagging on the CVV (cc_code) — this is the one spot where encryption alone doesn't quite get there. The card brands' rules (PCI) treat the CVV as something that can't be retained at all once a payment's authorized, even encrypted. So rather than encrypt it, the usual move is to stop storing it and drop the column once nothing in-flight still needs it. Is that something the new web-DB design could just leave behind?
• On the website passwords — when you say encrypted, are those one-way hashed (salted), or two-way encrypted? Either is a big improvement over before; just want to make sure I've got it right in my notes. (And if anything in the app ever emails a password back out in plain text, that's a good one to retire while you're in there.)
• The new web databases landing on 0.55 — since that box also has the accounting data on it, is the new web login scoped so it only sees its own web databases and nothing on the finance side? If it'd help, I'm glad to sit down and work out the exact minimal permission set for that login with you so it's tight from day one.
• Last one, just to be safe: does the back-office billing engine still point at the main server (8.62) for cc_file? I want to make sure none of the auto-billing gets caught up in the website cutover.

On our side, we'll take the stuff you shouldn't have to think about — locking down the server itself, cleaning up some old backend job credentials, putting a web application firewall in front of the site, and tightening the network around the database servers. That all runs in parallel with what you're doing and doesn't need anything from you.

One thing that might save you some hunting: when we looked through the site we mapped every spot still building SQL the old inline way — I can send you that list as a checklist so the stored-proc conversion doesn't miss a page. Just say the word.

Really glad we're rowing the same direction on this. Let me know a good time to connect if it's easier to talk any of it through.

Thanks, Mike / Arizona Computer Guru

---

Notes for Mike

• CVV is framed as a "heads-up / usual move" with an ask, not a directive — the one must-fix, softened.
• Every other technical point is a question, not an assertion (key location, hash-vs-encrypt, web-login isolation on 0.55, billing-engine path).
• The quo() fix-list is offered as a convenience checklist, not a handed-down to-do.
• Held back for the live conversation: key-management depth, the co-location-on-finance-server risk specifics.