Best practices for securely storing newly generated wallets programmatically

I'm working on a project that generates wallets for users, and these wallets aren’t controlled by the users themselves. What do you think is the safest way to store newly created private keys programmatically? Right now, here’s what I have: it creates a new wallet using randomness from user input combined with some randomness from the server. I then encrypt the private key with a password that's kept offline, erase the unencrypted private key from memory, and save the encrypted key in the database. What suggestions do you have for improvements or changes?

A wallet that is not controlled by the user? You mean a custodial wallet? A wallet that I can never recommend anyone or advise anyone to use. Or a web wallet like Blockchain.com in a way that the user will also be able to have full control? The private key are encrypted online in a database. I can not also recommend or advise anyone to use it. I prefer wallets that users can be able to generate their keys offline just like Electrum, Sparrow and Bluewallet.

It's a casino-type platform where players can play against eachother, if they were able to control their own keys they would be able to run off if they lost to others

Implementing an on-chain casino is probably not going to work very well if every bet involves a transaction. Maybe you can implement it on the Lightning network instead. Otherwise, you are probably better off holding player balances in a database and have deposits and withdrawals go through the casino's wallet.

Since it's for business usage, i would make these suggestions. 1. Do some research on TEE (trusted execution environment). It's feature provided by CPU or SoC to manage sensitive data more securely, although some people distrust it due to various reason (e.g. consider Intel ME as a backdoor or security issue). 2. Unencrypted swapfile bring security concern, since sensitive data may be stored there temporarily. Although i agree with @odolvlobo to simply have few casino's wallet and database which track user's balance along with it's changes, since your user currently doesn't have access to their private key anyway.

All bets are done server side with random.org, I've implemented user wallets so that transaction fees are lower I looked into this and this is exactly what I was looking for, you're right about the INTEL ME backdoor I worry about, but due to the processor I use I can mount additional firmware and hopefully make a solution that doesn't piggyback on preexisting TEE on the CPU. Will keep the thread updated if I have any more questions.

How do user wallets make transaction fees lower? I assume you would have a transaction from casino wallet to user wallet for payout which the casino pays? And for withdrawal from user wallet to user's own personal wallet the user may be able to choose transaction fee rate based on his needs (guided by reasonable fee rate suggestions according to current mempool state)?

That doesn't sound provably fair. I think OP confuses the meaning of "wallet" and "account". Considering the kind of questions he asks, I don't think he should be building a casino.

Can you please elaborate on this? How does the user provide randomness? How does the server couple the randomness with user input? Is this a raw password? Do you keep the raw passwords anywhere? If so, this needs some sort of amelioration. You should apply a hash function on the raw password and then encrypt the key with the result of the hash. So instead of doing: you should do:

Allowing the user to contribute entropy to the private key generation creates a weakness if they can gain information about what they contributed.

That's exactly why I asked! Randomness should be system-provided and then what the user should be responsible for deciding is the amount of security they will provide upon this randomness using a strong encryption password.

You wrote before that you don't want to give the user control of the address, so private key generation must be completely out of their hands. I don't understand the point of giving the user the ability to determine the level of your security. Maybe 2-of-3 multisig is the approach you are looking for. You have 2 keys so you have complete control, and the user has 1 key so they can spend with your approval.

A wallet that its user does not control it, don't fool me, but maybe you did not express your idea correctly as you wanted. It's your private key, it's your bitcoin and it's not your private key, it's not your bitcoin. Your wanted wallet is like custodial wallet, that does not give its user private key, and don't give any bitcoin to their user technically. I don't want to make you sad, but it is not a good and safe wallet for Bitcoin users. https://www.youtube.com/watch?v=AcrEEnDLm58 https://www.lopp.net/bitcoin-information/recommended-wallets.html Your wallet is likely controlling keys and users are not controlling keys.

Sounds good, but how do crypto casinos work today? If I have your username and password and log in, can I withdraw your funds? I am almost certain I can, but I don't really use gambling sites anymore, that's why I ask.

It sounds like OP is confusing the client seed for the casino part with the private key for the deposit address. The former makes sure the casino can't cherry-pick their server seed and thus cherry pick the random results. The latter makes no sense, users have nothing to do with the private key on deposit addresses (it's not their wallet).