509 karma · joined June 23, 2019
Any person who, with the intention of securing an unlawful gain for themselves or another obtains for themselves or another data that are stored or transmitted electronically or in some similar manner and which are not intended for them and have been specially secured to prevent their access shall be liable to a custodial sentence not exceeding five years or to a monetary penalty.
If I would avoid env then i need to put it in some kind of conf file and configure the app to read this file (e.g. mount into container). If I use a fault then i need some kind of credentials to receive the credentials.
So again what do I gain if I avoid env variables in containers?
E.g. if my app needs a db connection I can ask a vault service but I need creds for that. The vault service can rotate the creds very fast but is it addition security.
Banking has no selfservice password reset. A lot of work for customer support due to identification. Nobody wants to do that for free and if the accounts are freenyou may get DOSed by bots which trigger passwort resets.
A lot of services have password reset email features. If the email account has passkey you're screwed. But restore by snail mail can be possible but slow (for paid services). More secure? Don't know but same category of problems already known due to sim swapping attacks in mobile sector. But for sure the Mail account is a high value target.
Storing passkeys in a database may be possible but complex to do it right e.g. backup verification, avoiding to leak while backup etc.
Second: The provider can get the passwords with a simple server change.
> IMPACT. Complete compromise of vault confidentiality and integrity. The adversary can read and decrypt all vault con- tents encrypted after the attack, including passwords, credit card information, secure notes, and other sensitive data stored in the vault. Similarly, they can inject new items into the vault after the attack. REQUIREMENTS. The client fetches key material from the server, for example due to the user logging in on a new device. If executed on a non-empty vault, the attack results in the client losing access to all items already in their vault, while leaking any new items added to the vault after the attack took place. If the attack is executed at the time of vault creation, the attack is effectively undetectable by the client, since it cannot distinguish between a ciphertext it created and the ciphertext created by the server during the attack. PROPOSED MITIGATION. A straightforward mitigation is to have the client sign vault keys using the RSA private key in the keyset before encrypting them with the RSA public key. Ideally, two different key pairs would be used for...
from the paper: https://eprint.iacr.org/2026/058.pdf
https://www.reddit.com/r/europe/comments/9ziqfi/european_cou...
I would say online access is as necessary as a car. Possible without but less flexible.
Don't know much about the architecture about wayland but I think grahic driver handling changed in wayland too.