What are the physical security features that prevent the cryptographic data on a SIM card being read? In his excellent answer to "How does a SIM card prevent cloning?", user Lie Ryan explains that SIM cards have their critical data stored in "tamper proof housing", protected by "physical security measures [designed] to make reading the key from the card very difficult".

What are these "physical security measures", and how do they work?

Has anyone ever successfully read the security key directly from the physical memory of a modern SIM card?

SIM cards are just smart cards, so apart from pointing to the generic definition of Tamper Resistant, I'm not sure much can be said in general.

Looking up the manufacturer specs may provide additional info. For example, Gemalto (a specialist in hardware crypto chips) manufacturers a large number of the world's SIM cards. Their marketing page says this:

  With a microprocessor base, SIM cards are similar to a mini-computer with its own operating system, storage and built-in security features. When configured with up-to-date cryptography, as recommended by NIST, BSI, ANSSI, etc., SIM cards provide a level of security that is state-of-the-art.

That's all kinda vacuous and fluffy, bet it's reasonable to assume that SIM chips will contain similar security technologies to Gemalto's FIPS 140-2 certified products.

This excellent answer by @ThomasPornin is also relevant:

https://security.stackexchange.com/a/31051/61443


TLS Renegotiation Indication Extension vulnerability I am trying to understand the TLS Renegotiation Indication Extension from the RFC. I can understand that it is related to the fact that the renegotiation is sent under the encrypted stream, but I cannot undertand the idea and the exploit.
Could anyone please explain it to me in layman's terms so as to be able to understand this and read the RFC?

Marsh Ray's blog seems to be down at the minute, but you can read more on Eric Rescorla's blog (I'm using the same example application data here) or in this PDF (archive.org copy).

The genuine client sends a Client Hello (GenCH) to the server, but this is intercepted by the MITM.
The MITM keeps hold of it and starts its own handshake by sending a a Client Hello (MitmCH) to the server too. It completes the handshake normally and sends some application data. For example:

GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This:

The MITM now forwards the initial Client Hello (GenCH) to the server.

As far as the client is concerned, this is not a re-negotiation, but the initial negotiation. It can't tell the difference. The handshake completes and it sends its own request:

GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1
Cookie: victimscookie

As far as the server is concerned, receiving a second Client Hello (GenCH) is just a re-negotiation (which either party was able to initiate at any point in time) following the initial handshake initiated with  Client Hello (MitmCH). The application layer is treated as continuous. This is what the server sees:

GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1
Cookie: victimscookie

This way, the attacker is able to alter the request line (and thus query parameters) and insert its own headers, while keeping the cookies of the genuine client. The MITM doesn't get to see or alter what the client sends, but it's able to add content before, which is treated as part of the same request on the application layer.


How to filter ciphers based on ssl certificate? I have many ssl certificates.
On one of the certificates I run the command openssl x509 -in cert.pem -text -noout
it shows:

Signature Algorithm: ecdsa-with-SHA256
Public Key Algorithm: id-ecPublicKey

Based on the info from the certicate , how can I get the list of all possible ciphers which can be used with the particular certificate ?

-addn : https://tools.ietf.org/html/rfc5246#section-7.4.2

Signature Algorithm: ecdsa-with-SHA256

This is irrelevant for the choice of cipher.

  Public Key Algorithm: id-ecPublicKey

Since this is an ECC key you can use all ciphers which use ECDSA for authentication or the TLS 1.3 ciphers which are not specific to the key algorithm. Similar with an RSA key you can use all ciphers which use RSA for authentication or TLS 1.3 ciphers:

$ openssl ciphers -V ALL | grep -E 'Au=(ECDSA|any)'
$ openssl ciphers -V ALL | grep -E 'Au=(RSA|any)'

Note that above command also includes insecure ciphers, i.e. you might want to replace ALL with HIGH to get only the more secure ones.


How VIP card helps in verification? How does the 6 digit randomly generated security code from (disconnected) Verisign Identity Protection card help in verification/validation of any user?

Why one cannot enter any random 6 digit value instead of generating that value from VIP card/device?

Is there any fixed pattern of getting those values from that VIP device/card so that the server can verify that number?

You need to read about MFA tokens.

The numbers are sync'ed between the card and the authentication server. They have to match and they change. As part of the algorithm to generate the number, there is info from the device itself (serial number) so that the system knows that the number is associated with a unique device (yours). Mixed with your credentials, you have a very strong authentication scheme.

What benefit would it be to type any random string? It has to match SOMETHING on the server for it to mean anything.


two encrypting / hashing case, which one is best Thinking about these below two cases, which one is best and most secure one

1st case

//key1 generated from static salt and user password, because in case attacker don't know about source code (bad assumption, but still my assumption), attacker have only hashed or encrypted data + random generated salt
staticSalt = "StaticSalt"
key1 = pbkdf2(userPassword, staticSalt, iteration)

//key2 generated from key1 and randomSalt, this will be actual key to be used for encryption
randomSalt = GenerateRandomSalt()
key2 = pbkdf2(key1, randomSalt, iteration)

aes.Key = Key2
aes.IV = aes.GenerateIV()

or

2nd case

//directly generate key from randomSalt and password
randomSalt = GenerateRandomSalt()
key1 = pbkdf2(userPassword, randomSalt, iteration)

aes.Key = Key1
aes.IV = aes.GenerateIV()

My question is, is there any drawback in using 1st case, will it increasing or decreasing entropy, or making is less secure?

or 2nd case is far more better and secure way to do

Looking for answer from some crypto expert.

It doesn't make a difference other than the number of iterations of the hash. Entropy doesn't matter in a salt, only the uniqueness matters. Random input is the easiest way to get uniqueness but any uniqueness is equally valuable.

The first step really doesn't add anything as a rainbow table can be built for the first step and give inputs to try for the second in bulk.


Is gender considered PII (Personally Identifiable Information) under the GDPR? Since GDPR is shaking everything up at the minute I'm working on a few changes to our website/process.

I work in eCommerce in UX (UK based) and support marketing teams with certain activities.

My question is, does gender of an individual count as PII?

We store gender in a data layer as a JavaScript variable which is held within our own business, we then can choose to pass these variables across to a testing platform to target individuals based on the presence of these variables. As I'm not a legal/data type person I'm not 100% sure if by us storing and having the means to pass a person's gender (pulled from info we get when they create an account with us) to a third party, we are breaching any kind of information security agreements?

If this is down to company policy etc. then just let me know and I'll close the question as it's not really for here.

The definition of personal data as mentioned in the GDPR:

  ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

As you state that you use the presence of the variable to target individuals, the gender definitely has an indirect reference to someone's identity and as such, is personal data. However, that doesn't mean that you have to stop processing the gender in the context you described.

From a risk perspective (which is what the GDPR is all about), I don't see an issue if you only share the gender - which is actually pseudonymised since you don't supply any other direct identification data along with it.

However, you do have other obligations w.r.t. the transparency principle, incorporating the processing activity into your processing register, determining legal ground for processing (and acting accordingly), determining processor-controller relationship with your third party and including the necessary clauses in the the contract, etc. To determine all this, much more information is required than you have supplied in your question and I highly encourage to seek (legal) professional advice to support you in this matter.


Using plain-text phrases as public/private pair? I'm working on an application that'll be used by relatively non tech-savvy users, and while the machines will have internet access, the app can't have any sort of hosted intermediary.

The app allows people to take a file, compresses it down and encodes it as an image for sharing on sites like GitHub to aid in sharing things like test files etc.

The first version of the app works just fine, but sometimes there's data that needs sharing that is sensitive and some level of encryption is called for.

Ideally I want to go down the public / private key pair route, but sharing these is cumbersome and complicated from the user's perspective.

I'd like to be able to (somehow):

Take a user's e-mail address and use this as the public key
Take a password from the user and use this to derive a private key
Entangle these somehow such that they can be used in this manner.

It doesn't really matter if the e-mail address ultimately resolves to something else that is then used, but the general flow needs to be such that:

Alice wants to encrypt an image for use by a particular user
Alice types in the e-mail address of that user (or some other string for the target - e.g. a group)
Bob downloads the image into the app and types in his private password to unpack it.

The app could also sign the data using the private keys for verification on the other side as well.

I know I could use a password-derived public/private key, but that means that the single password could be used to derive both parts, and would make it ultimately useless.

You cannot use arbitrary strings as private/public key pairs. These needs to be generated according to the math specifics to the PKI algorythm you use (RSA for instance).

You could, however, create an application that uses the same workflow as you described but uses PKI for encryption, as long as you're ready to make some tradeoffs.

First, it starts with a typical asymmetrical encryption (use a standard library please: don't try to code one yourself): you app uses the sender's private key to sign the data and the the receiver's public key to encrypt it. The trouble is that, quite often, you don't have access to a validated public key for the receiver.

To solve that, you  have all users generate their own key pair (or pairs) and register the public key(s) on a common platform (a key server). This should include some form of user validation in order to make sure the key really belong to the security principle that is associated with them or you run a risk of someone registering a key with an identifier that doesn't belong to them.

So, when a user needs someone's public key, it can request it from the key server (over an authenticated, encrypted channel) as needed.

Of course, the devil is in the details: building such a system is extremely hard: you need to have a validation system for the keys that is both efficient and practical. Also, you need to take into account the fact that users will routinely lose their own keys, forget their passwords, change their email, etc. The key servers needs also to be extremely secure and, at the same time, operated in a transparent manner because anyone controlling them also control everyone's communication (they could replace any public key by their own more or less transparently).

All these "little" details are extremely hard (and expensive) to solve so unless you have a LOT of resources available, you'll probably be better off with sticking to simple symmetrical crypto.


How safe is Firefox Developer Edition? I've downloaded Firefox Developer Edition and it seems pretty good but I'm wondering how safe it is.

I know that there are already some posts about developer editions of browsers such as Chrome and Firefox but I saw that people talk about a beta program. This doesn't seem to be the case with Firefox Developer Edition.

Can I use Firefox Developer Edition as my main browser? Is it secure as Firefox 'normal' edition?

Yes, you can use the Firefox Developer Edition as your main browser but it has slightly different privacy and security properties.

Most notably, Firefox Dev comes with additional development and debugging tools, some of them still experimental. That means more responsibility for the user and potentially a bigger attack surface since fresh features can be more likely to be vulnerable.

  We'll include experimental tools that aren't yet ready to ride the trains to release.

You are also using the new features of the Aurora build (pre-beta).

  By using the Developer Edition, you gain access to tools and platform features at least 12 weeks before they reach the main Firefox release channel.

Because of the developer-centric design, it's easier to make insecure settings. For example, in Firefox Dev you can disable signature enforcement which would result in the browser accepting unsigned extensions.

  What are my options if I want to install unsigned extensions in Firefox?
  The Developer Edition and Nightly versions of Firefox will have a setting to disable signature enforcement.

Firefox Dev collects usage statistics ("Telemetry") by default which impacts your privacy.

  Usage statistics or "Telemetry" is a feature in Firefox that sends
  Mozilla usage, performance, and responsiveness statistics about user
  interface features, memory, and hardware configuration.
  [...] This feature is turned on by default in Nightly, Developer Edition (Aurora), and Beta builds of Firefox to help those users provide feedback to Mozilla. In the general release version of Firefox, this feature is turned off by default.

If you're concerned about these points, you could also just use the default build and install additional developer extensions later when you need them.


Security implications for email address and url changes? recently, we are seeing some From:, To:, Cc: addresses being
rewritten from user1@companyA.com to:

https://3c-lxa.mail.com/mail/client/mail/mailto;jsessionid=36725F1B090973DAF815646A3B096862-n1.lxa15a?to=user1%40companyA.com

i've checked RFC 822, and 2822 and the above does not
seem to be valid address specification formats.
Are there some other RFC or email clients that handles the
above links ?

Also, links in the emails of the form www.companyA.com are
also rewritten into:

www.companyA.comhttps://3c-lxa.mail.com/mail/client/dereferrer?redirectUrl=http%3A%2F%2Fwww.companyA.com%2F

what could have caused the above changes and what are the
implications ?

What program are you using to view the email?

It looks as if you are using the web interface from mail.com to read the email (mail.com is an email provider).

If this is the case, they are simply using an intermediate script as target of the addresses. When you click an address from the webmail, the goal is that the user writes a new email to that address, so it needs to be rewritten, instead of having the webmail opening a local MUA.

In the second case, where it is a http url, the name suggests that you are being redirected through https://3c-lxa.mail.com/mail/client/dereferrer?redirectUrl=… in order to conceal the url from which you were reading your email, as that might contain sensitive information, such as session tokens, your address, etc.


Can an attacker gain any information from an application/octet stream if they have no access to the sending and receiving code? Essentially, I'm wondering if an octet stream is, by its nature, secure without knowledge of a semantic meaning for the bytes being sent.  If you have no knowledge of the processing at either end of the stream, is there any way to get information from it?

Real-life data has a lot of structure which makes recognition easy. The Unix file utility has done so since 1973.

Not being able to figure out the ins and outs of a bunch of bytes means that the bytes are not distinguishable from random, unless you know a "secret convention" which governs the interpretation of said bytes -- this exists and is called encryption. Decades of research in cryptography have come to the following conclusion: encryption can exist, but it is not easy. If you do not apply encryption explicitly, then the meaning of the data is not secret but, at best, obscure. Experience shows that obscurity rarely lasts long.


Are EU cookie consent forms safe? Does the EU consent form system pose a new security risk?

Today we have to click OK on about 20 cookie consent forms every week, where previously we could mostly dismiss internet forms as being invasive and risky.

There are so many EU consent forms, I feel more likely to confuse a disguised download consent form and a security attack with an EU consent form. How big a risk do EU consent forms represent?

It increases dialog box fatigue. By overflowing the user with mundane dialog boxes, they are more likely to get into the habit of just clicking OK to remove the dialog box from their screen. This increases the risk of a user clicking OK on some important security decision presented in a dialog window.


Mixing stateless and stateful firewall rules I have been advised that mixing firewall rules that are both stateful and stateless can lead to trouble when it comes to troubleshooting. Is there any truth in this?

Take the following two rule sets (iptables):

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate NEW,INVALID -j REJECT

and

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j REJECT

Functionally, I can't see any difference. But maybe that's just my inexperience talking, is there really a benefit of one over the other?

Using state-based filtering across the board in an effort to make troubleshooting a firewall ruleset easier will not work out as intended. The result is likely to be quite the opposite.

State is just another characteristic to filter packets on. There is not reason that each rule in a ruleset should use the same characteristics. Or that "stateful" is somehow an inherently superior approach.

For a ruleset easier to be set up accurately, easy to troubleshoot and easy to update without breaking things it needs to be comprehensible to the administrator. It will be easier to understand if the rules are expressed as simply as possible. So additional filtering characteristics - particularly those such as state which are harder to follow in your head - should be used only when necessary.


Store provided external user data encrypted in the database I hope this is the Right Place

I have implemented a full user encrypted data storage solution. This works well and I can sleep well in the knowledge that neither I nor anyone else except the user can access the data ( AES 265 encrypted should hold for a while). All thanks to you guys. Here is an honorable backlink to the used Algorithm:
Store encrypted user data in database

Now to the problem. The customer no longer wants to manually pass the data into the storage and proposed that we integrate with two (my guess is the number will grow) external services that are trusted by the user and should, on behalf of the user, deliver additional data into our database.

How can this be realized without fully butcher the security existing in my current solution?

Currently, I have two ideas on how to resolve this situation:

IDEA 1:

Each User has an RSA key pair as well (The Private key is also encrypted like the Data Encryption Key).
The Service generates a new Data Encryption Key for each user and request pair and encrypts that with the Public RSA key
The encrypted password will be stored until the user logs in and then re-encrypted

This was the best solution I came up with so far. But not all users are regular and I am sure some will use the automation provided and use the service as a secure drop off place (which I do not mind) but I threaten the RSA security over time. Or maybe I am overengineering and the orange part is not necessary at all.

IDEA 2

I switch my whole AES encryption to RSA with a very high bit rate 15'000+. And eat the performance loss

This seems like an easy but not very future proof solution. given the emergence of quantum computers

Any thoughts on my ideas and any help are greatly appreciated

EDIT
I was asked to provide some more context.
My customers store highly personalized data which makes user identification and tracking extremely easy and is valued by other companies for data mining. Since a  data leak can result in personal damage as well as in some cases loss of face. I and my customers value a higher encryption standard to keep their data firmly in their control.

The Services are preidentified and then confirmed/trusted per user. They communicate over an https secured connection but with no further added security. They will push data to the secure storage and then drop the data or secure it internally. No user session /interaction is required.
The data they provide is gaining value in conclusion with the rest of the data stored in my system or over a large period of time.
But since I expect the number of integrated services will grow so will the worth of the data overall services -> that's why I am interested in fully restricting the access to the user.

I'm not even sure how your Idea #2 is supposed to work - you don't ever encrypt anything with private keys, and I'm not sure how your retrieval flow would decrypt the data if you did since you apparently would have used a different key depending on how the data was sourced - plus RSA makes an absolutely lousy bulk data cipher and there's literally no reason to ever attempt to use it as one.

Idea #1 is valid, though. It does have some "gotchas" but the basics of it are solid. Provide a public key (after authentication), data is encrypted (and gets a MAC / signature) using a random DEK and then the DEK is encrypted using the public key and stored along with the encrypted data. Retrieval requires using a password-derived key (PDK) to unwrap the private key, which then unwraps the DEK for that item and the DEK is used to decrypt the data. Elegant in theory, although there's some stuff you want to look out for (like, what if a user changes their password? Then the PDK changes, so you need to unwrap the private key with the old PDK and re-wrap it with the new one).

One thing that's not entirely clear from your description of the service is where the encryption and decryption is happening. For this sort of end-to-end, zero-trust encryption to work, you need the client to be the only one who can unwrap the DEKs, which means the server can never even receive the data necessary to derive the PDK. It also means the client must do 100% of the encrypting and decrypting, because the server neither ever sees the keys nor the data in plaintext.

In a system like that, you need a certain amount of complexity in your client; it's unavoidable. You can do this with a modern browser no problem - the modern JS crypto library is quite capable of all this, and there exist polyfills (of varying quality) for older browsers if you don't mind the performance cost of implementing crypto primitives in JS - but you can't do it in some external service that wants to push data to your system and the only parameters it accepts are "what credentials do I use and what URL do I send the POST request to?".

You'd need some sort of middleware that can take the data from the external service, authenticate to your service, and perform the crypto before pushing the encrypted data to your server. This is entirely possible but definitely increases complexity. It gets even worse if you need to be able to retrieve the data through such middleware; inputting data can be done without needing a PDK (since the PDK is only needed for the private key) so it doesn't need the real password and can instead use an API key or similar (sufficient to retrieve the user's public key, but no ability to unwrap the private key needed for the DEK). However, any client that wants to retrieve data needs to be able to unwrap the DEKs, which means it needs to unwrap the private key, which means it either needs to know the user's actual password (although it still never sends it to the server, otherwise the server can also unwrap the private key) or the private key needs to be wrapped (encrypted) using multiple client-specific keys (one is the usual PDK, another is based on some secret stored in the middleware or whatever) or else the client/middleware needs to store the private key long-term.


Distribute Program with Sheets API Credentials I am trying to write a program that uses the Google Sheets API to read spreadsheets and operate on the data.

My program contains a credentials.json file which I obtained from the Java Quickstart page (also obtainable from the Google Developers Console). I cannot use the Sheets API without it.

I want to distribute my program to a few consumers. However, I am not sure what the risk is of distributing a program which contains this credentials.json file.

Anyone think he can enlighten me on the matter? Is there perhaps a safer alternative?

EDIT:

Looking the current answers, it seems that correct approach is OAuth 2.0. However, looking also at the Authorize Requests page and the Using OAuth 2.0 with the Google API Client Library for Java page, it seems that I still need to include some identification for my application before I can complete the authentication process. The only identification I know of is the API key and the client ID and client secret pair.

Just as a rule of thumb, I know I should not be distributing anything that has the word "secret" in it. That being said, I have seen other applications - such as Stackexchange - which you can authorize to access your account, and they are all able to identify themselves to Google Sign In. If these applications/sites can identify themselves to Google without presenting any security risks, then I am sure I can do the same.

Only one problem... How should I identify my application?

I am a Google GDE Cloud Platform, security is my specialty.

The credentials.json file that you mention contains the Client ID and Client Secret. With this credential file, an attacker can create credentials for any Google Gmail/Gsuite/Identity email address. This will allow anyone with access to these secrets to create credentials with any "scope" they want and access/read/write/delete data in Sheets, Drive, etc. A hacker could host trojan software or distribute pornography from your account.  Therefore distributing your application with this file is a very bad idea.

The correct approach is to implement OAuth 2.0 on your public web server, returning an Access Token to the user. The user then includes this Access Token in the HTTP Authorization header. Google Sheets verifies this token. This is not hard to do and there are many examples on the Internet. There are also free/almost free services such as Auth0 to do this for you.

[Update after question update]

There are two methods of doing things. The easy method and the secure method. I will discuss the secure method.

Do not provide private secrets of any form to the client. It is OK to provide the Client ID to the client as this is considered a public secret. The Client Secret must be protected.

The following is often called three-legged OAuth.

This means that OAuth is implemented at your web server (or a third party service). The client never sees the secrets. The client goes to a page on your website, your site redirects the user to Google, Google performs the authentication and calls back to a URL on your web server with the token information (Access Token, ID Token, Refresh Token).

Why do you want to implement OAuth this way? Google Sheets require the OAuth tokens have OAuth scopes and you do NOT want to permit a client program/browser to specify scopes. Scopes are permissions. You must control what permissions a client can have.

The opposite of three-legged OAuth is two-legged OAuth. This happens in the browser and is not secure for your requirements.

[Update on two-legged OAuth]

One item that was not specified in your question, is "whose" data is being accessed. If your app is accessing a user's private data, then the user is granting your app permission to access their data. If your app is accessing your private data, then you are granting the user permission to access your data.

If the use case is you are accessing the user's data, two-legged OAuth is OK (three-legged is the best method). This method can be completely implemented in the browser. However, for all OAuth methods, Google requires that you have a verified domain name and a website for customers to refer to. This once again makes three-legged OAuth the correct choice.


How to do role-based authorization with OAuth2 / OpenID Connect? I'm trying to use OAuth2 for authentication/authorization, but after much reading around, I am confused... I'm trying to understand how OAuth and OpenIDConnect relate to each other, and how exactly I can use them for authorizaton.

From what I understood so far:

OpenID Connect is best for authentication, OAuth is best for authorization
OAuth2 authorization is done through scopes
A scope is the permission given BY the user TO a client, validated at the resource server
an OpenID Connect id_token is meant mostly for the client application, to provide user info, and NOT as a way for the resource server to validate the user

Here is my use case:

I need provide SSO to a set of completely stateless webservices made by us
OAuth is restricted to resource_owner grant
The identity server is provided on our side, and connected to an LDAP server
Only trusted apps can be registered as service providers

And what I'm trying to do, which boggles me:

Only authorized users can access a given webservice API

So, I need some way to check the permission given BY an external entity TO an user, at the resource server. Which, I believe rules out the use of OAuth for authorization?

I'm not sure how to accomplish this with OAuth/OpenID connect, or even IF it fits my use case.

Can role-based access be made to work with OAuth2 scopes at all?
Would it be ok to pass the id_token to the resource server, with a claim containing the user's roles (and discard the access_token altogether)? So the id_token would be used for both authentication & authorization. Given that the id_token is signed and contains hashes, it would be fine, right?
Should I just authenticate with OpenIDConnect, by checking the presence of the id_token, scrap the access_token altogether, and develop my own role-based authorization system?

Apologies for the wall of text, I'm just not sure if I misunderstanding the scope of OAuth/OpenID Connect here. Am I making the wrong assumptions?

Thank you.

The role concept can be used with access tokens in OpenID Connect (Oauth2).

Consider that a scope is a request for claims about the user that should be included in the access token.  The API requesting access knows that it needs the (say) "employee" role, includes the "scope=openid roles" query parameter in the request.

The authentication server (AS) has access to role information about the user (for instance in an LDAP directory).  It can then look up the user's roles, and include them in "roles" claim in the access token.

You could also narrow the scope by requesting the role itself (scope=openid employee), in which case the AS could include it if the user is a member of that group.  This is a bit less scalable as it requires detailed knowledge about the required roles, but reduces the amount of PII in the token, and reduces its size.  Also, if the user is not a member of the specified group (ie, the scope cannot be included in the token), the AS must inform the API about this as per OAuth2.

The role use is fairly common, and some examples can be found on:

https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-id-and-access-tokens
https://connect2id.com/blog/using-openid-connect-to-make-assertions-about-end-users
https://www.keycloak.org/docs/latest/server_admin/index.html#roles

So as for questions 2) and 3): Don't do this :)


Usefulness of token sidejacking prevention mentioned by OWASP JWT Cheat Sheet I was just reading through the "Token sidejacking" of the JWT Cheat Sheet of OWASP (https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet_for_Java.html#token-sidejacking)

At the moment I don't understand how the recommended prevention actually solves the issue.

The solution is to add a context and send this context (e.g. a random value) as a Cookie as well as part of the JWT (then hashed).

However if an attacker is able to steal the JWT by performing a XSS attack and access the sessionStorage, the attacker can also send XHR-requests, so the Cookie is automatically send with it. If the attacker is able to sniff the network traffic, the attacker also has the Cookie value. The only case I can think of where this works is, if the attacker has access to some sort of logs, where the JWT is stored, but this would be another vulnerability (or more).

What did I miss? Thanks

if an attacker is able to steal the JWT by performing a XSS attack and access the sessionStorage, the attacker can also send XHR-requests, so the Cookie is automatically send with it

The solution uses SameSite cookies. They won't be sent to the attacker's server.


What is the benefit of having FIPS hardware-level encryption on a drive when you can use Veracrypt instead? The expensive one: https://www.dustinhome.se/product/5010873750/ironkey-basic-s1000
The cheap one: https://www.dustinhome.se/product/5010887912/datatraveler-100-g3
Over 14,000 SEK difference in price. Same company (Kingston). Same USB standard (3). Same storage capacity (128 GB). Same store.
Yet such a massive price difference. All because one is "encrypted"?
I don't want to sound either condescending nor ignorant, but why would even a very rich person pay such a premium for the "encryption"? Is there any benefit to have it in hardware (presumably some kind of integrated micro-computer?) over just formatting the cheap one with VeraCrypt? Is the expensive one far more durable as well?
Won't this thing actually age and become useless in regards to the encryption, whereas with VeraCrypt, you could re-encrypt it since it's all software?
I realize that trusting VeraCrypt in itself is also quite scary, even for me, but I somehow feel more confident about that software than I do about some company "promising" that it's "super duper encrypted with FIPS 140-2 Level 3, 256-bit AES-XTS"... Whatever that means. I doubt many people know.
I want to make clear that I recognize that there may be something I'm fundamentally missing, and that this could be extremely useful for people with a lot of money and no trust in VeraCrypt, or who need the convenience that this (presumably) provides. I'd love to hear a justification since apparently, that "built-in super encryption" costs so much money versus the identical product minus the encryption.
With that price tag, you'd almost expect it to be covered with real gold and gems...

super duper encrypted with FIPS 140-2 Level 3, 256-bit AES-XTS

Yet such a massive price difference. All because one is "encrypted"?

Your question is a bit like comparing a Toyota and a Ferrari and asking "Why the massive price difference. All because one is "fast"?
What is FIPS 140-2 Level 3?
FIPS 140-2 Level 3 is more than just encryption. It requires the device to be tested by a cryptography testing lab that is certified to perform this testing on behalf of the US government. The device must:

(Level 1) Have its crypto implementations inspected by the testing lab for correctness and backdoors.
(Level 2) "tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys" (wikipedia). Typically these are fancy versions of "warranty void if broken" stickers that are very hard to get off and put back on without damaging the sticker or the product in a very noticeable way. I've seen some where the sticker is like one of those glow sticks where bending it mixes chemicals and it turns a bright colour.
(Level 3) The device must be able to detect physical (or software?) tampering and wipe its own data. For a USB stick that probably means that any attempt to cut open the case will result in the device triggering either a software wipe or physical damage that makes it non-functional.

For the sake of completeness: Level 4, the highest level, adds the requirement that devices be resistant to physical attacks that subject the device to temperatures and voltages outside its normal operating ranges. This can lead to attacks like glitching where you manipulate the system clock signal to, for example, double-execute or skip instructions.
Level 3 is difficult to obtain. For rack-mounted servers, I've seen things like the entire motherboard and hard drive submerged in 5 kg of heat-conductive epoxy resin so that it's nearly impossible to remove the RAM sticks or hard drive without destroying them. I've also seen tripwires on the hinges of the server case such that opening the case causes destruction of the chip holding the crypto keys.
I'm not even sure how you would do this on a USB stick. I'm impressed that they got a USB stick past Level 3 testing. Guess: maybe there are tiny wires in the casing and an "intrusion detection" chip with its own battery that is never powered off so that it can monitor for breakage of the wires and trigger a wipe?
Target consumer of this USB stick
You are not the target consumer of this USB stick. You really have no reason to buy it.
Note that like all FIPS standards, FIPS 140-2 is not intended for consumer goods; it is intended soley for internal use by the US Federal Government and companies that it contracts to. This USB stick is intended for people who are doing contract work for the US government and are required by their contracts to keep all data on FIPS 140-2 Level 3 devices, likely because the data they are handling has been classified at a certain security level by the US government or military. Very specialized device for a very small market, hence the price tag.


How to protect a LAN from WAN with some kind of authentication we have a local network where some services run. Currently they aren‘t connected to the Internet. But now we want be able to reach those servers from the internet. Since those services are under development and have some kind of sensible data, we want a secure and easy to use network concept.

We thought about something like that: From the internet you can access a website like secure-example.com. If you go to this page the user needs to login and will see and have access to all services. On the other hand you can access like serviceone.secure-example.com, need to login and have direct access to the service.

I thought some kind of DMZ or DNS ALG should do the trick but I‘m not sure about that.

Generally, this is done with some sort of bastion host that has access to both networks (internet and intranet). At the simplest, you allow SSH access to the bastion host (for authenticated users only, of course) and then people tunnel through the bastion to reach the internal hosts. That requires setting up SSH tunnels, though, which isn't always convenient or user-friendly. An alternative is to have a login web app on the bastion (or even just use something like TLS mutual authentication with client certificates), and after the user is authenticated the bastion acts as an invisible or reverse proxy, taking requests meant for the back-end hosts and getting their responses, then passing those responses back to the (authenticated) users via a secure connection (probably just HTTPS, unless you're using a non-HTTP protocol in which case you might have to get fancier).

You could also use a VPN server to bridge into the intranet. Users authenticate to the VPN, after which it's basically as though they are on the same local network the VPN server is on (i.e. the same one as your internal services) until the VPN tunnel is closed or broken. There are a number of VPN technologies and they aren't all equally secure (anything using MS-CHAPv2, for example, is pretty easy to break), but most OSes support a number of VPN technologies out of the box, and there's also third-party software like OpenVPN (F/LOSS) or various commercial options.

The bastion host / VPN server, being a bridge between sensitive and untrusted networks, should of course be as hardened as possible. Don't run any more services on it than needed (good advice for any server, really), keep the program logic running on it minimal (to minimize attack surface; no need to by fancy), and so on. Keep it updated, maintain audit logs, and all that good stuff.


is it possible to test out remote host by using nmap? I was trying to test out my friend's computer (with agreement) by using nmap remotely. But the result I got seems kinda awkward to me. It only showed 1900 as tcpwrapper and all other ports were no responded. And OS detection was 3Com router not the machine I thought.

Is it because it blocks nmap scanning at router? I tested same network and other machines were revealed with various ports/services.

Any idea how to interpret this result and do some further testing on this machine?

She's probably using NAT.

Proper, publicly routable IP addresses are scarce and expensive. So, in a small home or business network, like most of us have these days, it makes sense for the ISP to only provide you with a single public routable IP address, and use some clever trickery in the router to allow all the devices in the network to share it.

While NAT lets home users do 99% of what they need to, there are many limits on what you can do when one is in place, and you're seeing one of them.

(To forestall the comments: obviously, from a security perspective, the fact that you can't easily do port scans from outside is a benefit, rather than a limitation!)


Botnet Attempting to Login to Website Our server has recently become a target of what appears to be a botnet attack.  The first indication was an insane amount of traffic to one of our client's websites - so heavy that the server entirely stopped responding.  I believe we had somewhere near 200 queued requests on the server when I checked on it.

I've concluded that it is a botnet because each IP sends at most 3 requests.  These requests seem to be targeting login/registration pages.  Originally they were brute forcing user info pages (/user/lkjasd) to see if the user existed, and then trying to login as them if not.

My initial response was to set some RewriteRules for that VHost that detected all of the login/registration/user pages and send 403's immediately (only administrators login on this site, and that is rare).  This has taken the load off our server because of the quick response, so all of our sites are back up.

However, I am now 3 days into that solution, and the attacks have not slowed.  They've cut out most of the login/registration attacks, and now are sending GET and POST requests to my homepage, with the referer set as /user/login.  I'm assuming this is an attempt to hijack a session or trick the site into thinking they just logged in.

Obviously I can't setup a RewriteRule to 403 on the homepage, so how else can I defend against this?  The traffic isn't unbearable, but it makes me uneasy just letting them run, and I'm a bit nervous about my bandwidth bill at the end of the month.

A DDoS attack is near impossible to prevent or stop at a local level.

I strongly encourage the use of a service like CloudFlare which is aimed at mitigating DDoS attacks. Another alternative is coordinating with your ISP to drop DDoS like traffic.

The recent Spamhaus DDoS attack demonstrates how effective a service like CloudFlare can be in mitigating large scale DDoS attacks. While the amount of bandwidth being thrown at the target is enough to almost overwhelm even individual Internet Exchange Points, the target site remained accessible throughout the attack.

Edit: Reading your question again, it appears that your login page only needs to be accessible to a few administrators. In that case, requiring a VPN to access the login page might do the trick. My previous point still stands though, if a determined enough attacker is willing to expand resources on your site, you can only mitigate attacks through a service like CloudFlare.


Should I regularly erase cookies? Cookies really do make for a better experience on the web but do they also create a vulnerability? How often should I clean them out and what benefits are gained by doing so?

Cookies by themselves do not create any vulnerability. The goal to delete cookies is merely to improve privacy by keeping websites from tracking your activity.

A common way to track users, for instance, is when you visit several websites which include contents from some defined third-party tracking service (this content may be advertisement for the end-user, media & formatting resources like images, videos or fonts, traffic analysis for the webmaster, etc.). Upon your first visit, the third-party service will create a new cookie in your browser, then you will send him the same cookie upon each subsequent website you visit, allowing the third-party service to track your activity over several websites during your navigation (the cookie itself being usually programmed to have a lifespan of several years).

Session cookies, i.e. the cookies stored on your computer after you successfully logged in some website, may also present a security threat since they can be compared as a key allowing you to access the website without authenticating again.

Keeping such cookies could potentially allow another person to act as you on a website (whether maliciously or by mistake). Automatically deleting them guaranty you that you do not keep such forgotten keys somewhere on your system, and that the next time you will access to the website you will have to authenticate yourself.

Different browsers offer different options to configure how cookies are handled. Usually these options are present in the browser's configuration screen below a Privacy section:

Refuse cookies: As the option states, you will just not use cookies anymore. I recommend to reserve such option only to very specific use-cases as it will have important side-effects, one of them being that cookies are the recommended and good way to handle your session tokens so disabling them will either prevent you completely to log in to some websites or make them fall-back to potentially less secure systems.
Keep the cookies until you quit the browser: It means that no cookies will be kept after you have closed your browser. It will prevent any possibility to track you using the cookies between two browsing sessions, and require you to authenticate again to the websites where you have an account.
Block third-party cookies: This is purely an anti-tracking feature since only the website you are currently visiting will be allowed to store cookies in your browser, this action will be refused to any third-party services. Enabling such option will usually have no impact on your session cookies (personally I did not encounter any unwanted side-effect to enabling this option, even if this may vary depending on the exact way you use your browser).

Moreover, most if not all browsers currently propose a private window feature: all cookies stored by the websites browsed while using this feature will be deleted upon window closure. Moreover, even if you visited the website previously in "normal" mode and it stored some cookie in your browser, it will not be able to access them when you visit it back while using the private mode.

This is a particularly good way to ensure that you do not mess with other people's cookies when using their browser for some search or as a quick workaround when you need to visit some website but want to prevent it to store or access any cookie.

Additionally, some browser may propose plugins allowing to even fine-grain cookies usage. A good example is Firefox's Self-Destructing Cookies. It's main use is to automatically delete the cookies a certain time after you closed the associated tab, but it can also delete all cookies after a period of inactivity of the browser (for instance when you come back from lunch, you will have to authenticate again to your websites), all these option being of course configurable.


How long to brute-force WPA password? Bob has a password (for his WPA encrypted wifi) which is 8 characters, all lowercase, and not a dictionary word.

Eve lives next door to Bob and wants to illegally hack his WPA.  The number of possible passwords is 26^8 (is that right?).

EDIT: The ssid is not common, and there is no rainbow table available for it.

How long will it take Eve to brute force that password if she has
a: a regular desktop machine from 2011
b: a powerful desktop, with GPU (does GPU help at all in this case?)
c: a GPU cluster of 8 cards
d: access to amazon cloud GPU clustering and a couple of hundred dollars.

another edit:

The UK's only cable ISP (Virgin media) provides a combined modem / wifi router.  This is supplied with an SSID of the form "virginmedia1234567" (The word virginmedia with a 7 digit random number), with a random password of the form "abcdefgh" (8 lowercase letters).  I have this router, and have changed everything.  Many neighbours also have this router.  I have no idea (and I'm not going to try to find out) if they've changed their passwords.

(a) a desktop CPU can do roughly 1000 passwords/second.
(b) a desktop GPU (graphics processor) can do roughly 80000 passwords/second, or 80 times the speed of a CPU, or 30 days to crack your hypothetical password
(c) a cluster of 8 GPUs is 8 times the previous number, or 8*80000 or 640k passwords/second, or 4 days to crack your hypothetical password
(d) Amazon EC2 uses older/slower GPUs

You say "not dictionary word", but it's more complicated than that.

The "dictionaries" used by password crackers aren't the "English dictionary", but dictionaries of known passwords. The most common dictionary is the list of 20 million RockYou passwords. These were passwords chosen by users of a website that was hacked. Once hackers broke in, they published all the passwords, so they form the basis of cracking dictionaries. This is many times larger than an English dictionary, and contains such things as "ncc1701" (Star Trek ship designation).

Furthermore, cracking looks at "mutations" of dictionary words. Thus, while your password may not be in the RockYou list, it might be a near match that will eventually be found.


Using Random Numbers As Session variables I am using randomly generated numbers as session variables to identify the sessions in a PHP application. To make further security proof what ways should I follow?

The best way to generate random tokens for security purposes in PHP is using openssl_random_pseudo_bytes() to obtain some random bytes, and then bin2hex to make them printable.

$token = bin2hex(openssl_random_pseudo_bytes(16));

You can safely use $token for your session identifier, CSRF tokens, etc.


TLS mutual authentication with self-signed client certificate Is there any security enhancement when I use self-signed client certificate for TLS mutual authentication?

There is an additional layer of security with user authentication on the application layer.
And the user authentication will be granted only if the presented client certificate is the same as the one presented on the user registration phase.

Origin-bound certificate might be another form of this approach.
The way Syncthing manages device IDs also looks similar.

If you self-sign with a personal CA which you then put in your trusted root, then it's reasonable. If you self-sign and then just ignore all CA errors, that's essentially useless. You offer no security in this scenario outside of passive traffic monitoring.

Adding client certificates to the mix only protects the server from unauthorised access attempts. It does little to protect against someone impersonating the server.


C:\Users\Public\ for sensitive data Installing a MS Windows based system that is to handle various sensitive data (accounting, personnel etc.). Somewhat to my surprise it consistently want to put everything under

c:\Users\Public\

where it is going to store reports, SQL databases, documents and so on. Is this a poor choice of location for such data?

Believe I can hack the system to accept using a custom path where I can set group access or the like if/when (selected) others are to have access. Would this be worth the work? (Have not used Windows for a long, long time.)

Have spoken with the provider about this, but they seem to have no advice regarding the issue.

The 'Public' profile allows anyone who can log into the system access to the contents. You may still be able to limit it with NTFS permissions, but if you are trying to do proper access controls via NTFS on the files you should really use a folder outside of the user profiles in general. Then you can block inheritance and set your own permissions.


Is there a standard way to check if a requirements.txt has potential security issues? Every open code repository has security issues. Attackers can use three ways to sneak malware in:

Abuse typos: Create a package with a similar name, but the package is malware
Malware + useful code: The library actually provides value, but also contains something malicious
Update existing code: Attackers could get access to existing legitimate packages, e.g. (1) finding the credentials of one of the maintainers (2) hacking the package repository itself (3) becoming a maintainer of a smaller package by legitimate "ownership transfer"

For Python, dependencies are often explicitly noted in a requirements.txt file. I know two tools to analyze this:

piprot: Check if packages are outdated
safety: Check if packages are in safety-db / known for issues

I would also be interested in size, e.g. I would consider some things "save" when they come from big, well-known companies (e.g. Google, Amazon) or belong to bigger organisations (scipy/numpy, Python Software Foundation) or if they have a lot of contributors on Github (maybe also stars / forks ... I'm not sure how easy it is to drive those numbers up, but at least it would show some activity).

Is there a tool which can check a requirements.txt (recursively) and check for low-participation projects which could potentially easily get malware?

All my github repos have requirements.txt files in them, and GitHub will email you a warning if there are security issues. (it appears that GitHub will scan any file named requirements.txt anywhere in your repo)

The dependency graph will also display some information.

As a previous commenter mentioned synk which is a nice tool, I found that for python, pyup was nicer as it allowed me to publish the results of the scan for anyone to see.

Hope this helps.


Are GET, POST and windows.location vulnerable to XSS in a Wordpress theme? I created a Wordpress theme for my client. He told me that he scanned my theme with a vulnerability scanner, and that it has security issues with the GET and windows.location methods. Is this really insecure? How can I fix this?
The errors look like:

Risk Factor:

Medium / CVSS Base Score : 4.3(CVSS2#AV:N/AC:M/Au:N/C:N/I:P/A:N)

Output:
Using the GET HTTP method, the scanner found that:

+ The following resources may be vulnerable to cross-site scripting (quick test) :
+ The 'product_quantity' parameter of the /pink-drool-proof-bib/ CGI :
/pink-drool-proof-bib/?product_quantity=--><script>alert(112)</script>
Thanks

If you have created a pure Wordpress theme (so only CSS) then normally there should be no issues. The problem is that the GET parameter product_quantity is directly shown into the page without properly sanitizing the output. This means that when you put JavaScript within the parameter, it will be loaded into the page (as it's shown) and it will execute the script.

Now if you use the windows.location to display variables in your webpage, it can very well be that you do not sanitize these before outputting them, hence making your page vulnerable to XSS.

You can read more at OWASP.


Example of how the remaining shellshock bash bug CVE-2014-7169 (taviso bug) could be exploited? I have a general idea about the Shellshock bash bug (CVE-2014-6271 reported Sep 24, 2014) of what the vulnerability is and how it could be exploited. Here you find examples on how to exploit the original bug CVE-2014-6271: What is a specific example of how the Shellshock Bash bug could be exploited?

Meanwhile, a patch is out on most major distributions which fixes the initial, although not the full, Shellshock vulnerability.

  There is a patch that prevents bash from interpreting anything else than the function definition in there (https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html), and that's the one that has been applied in all the security updates from the various Linux distributions.

  However, bash still interprets the code in there and any bug in the interpreter could be exploited. One such bug has already been found (CVE-2014-7169) though its impact is a lot smaller. So there will be another patch coming soon.

CVE-2014-7169 appears to be less severe but is definitely still cause for concern. So how would an example exploit look like for this remaining bug?

According to @taviso original post, the line

env X='() { (a)=>\' sh -c "echo date"; cat echo

is be sufficient to bring the shell to an inconsistent state. I tried it and after that, things are broken until you close that shell instance. Commands won't be interpreted correctly, parameters are treated like they are out of place unleashing incorrectly reported syntax errors, "man" shows an empty page, etc...


Combining HTTP smuggling & Trace HTTP method Context

While studying HTTP smuggling attack patterns, i found this nice article wrote by Regilero

There is one point that i want to clarify on the credential hijacking pattern. I was more or less able to reproduce this attack in my lab:

         [Attacker]                     [Proxy]             [End Server]
             |                            |                       |
             >-req. Smuggling[+Req.evil]->|                       |
             |                            >-req. Smuggling ------>|
             |                            |                       |
             |                            |<----- resp. Smuggling-<
             |<---------- resp. Smuggling |                       |
             |                            |                       |
 [Victim]    |                            | \-req. evil --------->|
     |       |                            | (pending partial req.)|
     >------------------- req. Victim --->|                       |
     |                                    >-req. Victim --------->|[+ pending partial req]
     |                                    |                       |
     |                                    |<----- resp. evil -----<
     |<---------------- resp. evil -------<                       |
     |                                    |                       |

scenario

Lets assume that the end server allow the trace method.
The attacker own a malicious domain.
The attacker will forge the response (resp. evil) to be a http 302 which redirect the victim to page that contain a malicious Js script.
The malicious script use the trace method on the endpoint server and store the response somewhere.

Question

Hoping that this scenario is not technically wrong, does the attacker had succeeded in stealing the victim's session cookies ?

You are talking about forging  redirect response. There are several problems with that:

forging a response means an HTTP Response splitting issue, but here the 1.5 query hijacking trick is an HTTP Request splitting issue
even if you were able to send a 302 redirect response to the user, this response would not contain the user credentials, and when following the redirection the victim's browser would not send the first website credentials.

But having a backend with TRACE enable may still be used in HTTP smuggling. That would be a quite complex attack, where a lot of things could fail, but that's maybe something you can reach in a lab.

The goal

we have TRACE available on the backend, so we want to force the victim HTTP query to be a TRACE query (implying building the first line of the HTTP query with a TRACE request and adding the real victim query to that unterminated query).
TRACE will echo the victim credentials (cookies) in the Response body
We want to see the response body (that's the very hard thing, as by default the response goes to the victim, not to the attacker)

Problems

Using the classical 1.5 query attack, where the Reverse Proxy thinks there's only one query, and the backend thinks there is 1.5 queries is already something quite hard:

you need to have a response from the backend for the first query in the pipeline (If you take Apache, for example, you will never get this first response until the pipeline is complete). This way the reverse proxy can believe everything is done and can reuse the tcp/ip connection with the victim query.
you need to have a connection reused between the Reverse Proxy and the Backend (so a keepalive connection or a tcp/ip sockets spool)
All this already means several exploits were used (to hide the 0.5 query from the reverse proxy, like with an hidden header, and quite certainly another to trick the backend in revealing this header and interpret the body as another unterminated query). It also means the attacker is quite certainly running a long loop of strange queries hoping to capture one of the victim query sometime (and that's a blind attack).

I made a video on this sort of attacks, the first example on this demo is a 1.5 query attack, and you can see that's a blind loop, but the victim is enforced in running a delete-user query on the application.

The result is only hijacking the user credential for the 0.5 query (so you decide for the user what is the query running on the backend), but the response goes to the victim, and he will see that the wrong query was done. You do not have the user credentials, you just have control on the victim queries. You do not even have the victim responses.

To exploit a TRACE query we need to get the hijacked query response...

So we need to add another smuggling problems, with shifting of the response stream. If we can add a shift in the order of backend response to the Reverse Proxy then the *trace response containg the credentials in the body** may not reach the victim. It may reach anybody, so maybe also the attacker.

Shifting responses

So how to shift response? That's the kind of attacks used in cache poisoning models.

Here it would be sending 2.5 queries, not 1.5. The reverse proxy would still think that's only 1 query.

         [Attacker]                     [Proxy]              [End Server]
             |                            |                        |
             >----req. A[+Req.B+Req.C]--->|                        |
             |                            >-req. A[+B+C]---------->|
             |                            |                        |
             |                            |<----- resp. A----------<
             |<---------- resp. A---------<                        |
             |                            |                        |
             |                            |      [*X*]\-req. B --->|
             |                            |                        |
             |                           [?1]<--- resp. B----------<
             |                            |                        |
 [Victim]    |                            |      [*X*]\-req. C --->|
     |       |                            | (pending partial req.) |
     >------------------- req. Victim --->|                        |
     |                                    |                        |
     |<------------------ resp. B-------<[?2]                      |
     |                                    |                        |
                                         [?3]>-req. Victim--->[+ending req C]
       [Someone]                          |                        |
           |                              |                        |
           >----req. D------------------->|                        |
           |                             [?4]<- resp.C[TRACE BODY]-<
           |<--- resp. C[TRACE BODY]-----[?5]                      |
           |                             [?6]>------ req.D ------->|
           |                              | (...) <--- resp.D------<

Ok, that's a big mess, shifting responses is always a big mess.

req B and req C are hidden from the reverse proxy (same attack as the classical one but you hide one complete and one incomplete response)
req C is a TRACE query, unterminated (unterminated header)
[?1],[?2] and [?3] may need to appear in a very strict and different order ([?1] after [?3], so [?3]-[?1]-[?2]), and that's tricky.
same thing for [?4],[?5] and [?6], [?6]-[?4]-[?5] has more chances of succeeding
if you have a way to control the timing of request B (slow query), you may succeed for [?3],[?1],[?2]. That's harder for [?4],[?5] and [?6]
socket buffering poisoning issues may help you avoiding these timing issues. The reverse proxy would store the response and reuse it on the next query (not checking that the socket already had a response before adding a request in it).
you have to hope the [Someone] will be the attacker, the attack is running on a loop so this may effectively happen (but it also means req. D is in fact req. A[+Req.B+Req.C].
there's more than one way to fail this sort of attack. That's really very theoretical.
who's still running Trace enabled backends? I known you can enforce it in Apache, but Apache cannot be the backend in this attack, has incomplete pipelines does not send early responses (so no resp. A and no resp. B).

Just for fun, same schema with [?3]-[?1]-[?2] and [?6]-[?4]-[?5] :

         [Attacker]                     [Proxy]              [End Server]
             |                            |                        |
             >----req. A[+Req.B+Req.C]--->|                        |
             |                            >-req. A[+B+C]---------->|
             |                            |                        |
             |                            |<----- resp. A----------<
             |<---------- resp. A---------<                        |
             |                            |                        |
             |                            |      [*X*]\-req. B --->|
 [Victim]                                 |                        |
     |                                    |                        |
     >------------------- req. Victim --->|                        |
     |                                    |                        |
     |                                    |                        |
     |                                   [?3]>-req. Victim--->[+ending req C]
     |                                   [?1]<--- resp. B----------<
     |                                    |      [*X*]\-req. C --->|
     |                                    |  (filled with victime) |
     |<------------------ resp. B-------<[?2]                      |
                                          |                        |
       [Someone]                          |                        |
           |                              |                        |
           >----req. D------------------->|                        |
           |                             [?6]>------ req.D ------->|
           |                             [?4]<- resp.C[TRACE BODY]-<
           |<--- resp. C[TRACE BODY]-----[?5]                      |
           |                              | (...) <--- resp.D------<


Alternatives to SELinux and AppArmor? With SELinux developed by NSA and AppArmor by Novell [*], what alternate solutions exists when trying to lock down a system and running applications, based on ACL and similar concepts like Zones on Solaris.

with applications i mean: services that are available and public accessible via network, namely all kinds of web/applicationservers, but also db-servers.

chroot is not an option, because its PITA to setup and maintain in the long run (experiences).

What i want to achieve: limit access of netbased services to its config- and datafiles only (docroot for webservers, dbs for db-server etc); outgoing connections are managed via firewall and service-proxies. if some attacker is able to access the system, he7she shall be limited on what to see and what to do, e.g. dont run programs, dont read other files.

[*] because of gag-orders and such, no trust anymore.

Grsecurity could be an alternative to selinux and apparmor on a linux machine. A comparison of the three tools is given over here.


How effective is MAC whitelisting on a Wireless Access Point? For the sake of context, let's say I set up my home router with WPA2, a strong passphrase and I whitelisted all of my devices.

I know the data is encrypted, but is the layer 2 header encrypted as well? Ultimately, is it possible for someone not connected to my Wi-Fi to extract a MAC address and spoof as it in order to get their hands on some free internet (or worse)?

MAC Whitelisting as well as Blacklisting are pretty much useless for security. Your strong WPA/2 passphrase however is great (if WPS isn't enabled).

As kub0x said, the Layer 2 info isn't encrypted. MAC addresses are fully visible: If you have a laptop or a wifi card, install or VM a linux distro and fire up the aircrack suite. With Airodump-ng, you can see the MAC addresses of WAPs and the MAC addresses of the clients. MAC spoofing is easy, so an attacker could definitely spoof the unencrypted MAC.

As for free internet, I'd say no. While they would masquerade as a whitelisted MAC address, they still wouldn't be able to decrypt the payload sent to them. Your strong passphrase has already encrypted the useful part of the data. Before they can get free wifi, they have to be able to send properly encrypted data to the WAP which it would decrypt. If it decrypts to gibberish (which it would if improperly encrypted, or not at all encrypted), it won't go anywhere. Further, in order for them to receive data from the router, and further the internet, they would have to decrypt those encrypted packets. Again, they wouldn't go anywhere.

The only chance they have of getting free internet with a MAC whitelist enabled is the same as if you had no whitelist enabled: they have to have your passphrase, or break in another way (WPS and Reaver).

The only thing MAC Black/Whitelisting does is prevent accidental connections to your WAP. Aside from that, I believe the listing does nothing.

Bottom line: you're still safe, but possibly not for the reasons you think.


GPG good signature but Warning: untrusted signature I'm having an issue with some of my clients being unable to open email attachments when I sign the messages. The error they get is something like (free translation):

  Error: cannot open. The digital signature could not be validated.

Checking the sent message with gpg produces the following:

gpg: Good signature from "John Doe <john@doe.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.

I would like to keep signing and eventually encrypt all communications leaving my office, but I need to solve the attachment issue.

How would I go about solving this? Is it a matter of the receiving end marking my signature as trusted? Is there a way to do this that doesn't involve an action from the receiver (key server?)?

Whom to Trust?

The signature could be successfully verified, that means it was really signed with the private key as announced. This key claims it belongs to "John Doe ".

Yet, your GnuPG setup does not trust in this key. Everybody could create a key for John Doe; all you know is somebody that created a key with user ID John Doe sent you this message.

Verifying Key Ownership

To be sure about whether the sender of this message is really who he claims to be (John Doe), you should get knowledge of his key id (better complete fingerprint) on another, trustfully way (it must not necessarily be secure, as only public information, namely his public key id, is transferred). After that, download and sign his key:

gpg --recv-keys 0x12345678
gpg --sign 0x12345678

All keys you signed (and thus their signatures) will be verified in future.

The Web of Trust

You can also make use of the web of trust. By putting trust on a key, signatures given by that key's owner will also be considered when verifying a key's validity. Have a look at this answer which explains trust, valid keys and the web of trust more in detail: What is the exact meaning of this gpg output regarding trust?


Passwords and Security by Obscurity I have read this site enough that I know that security by obscurity is discouraged and bad. However, why are passwords not security by obscurity? They are an obscure piece of data that when found allow access to an account. That is what I have come to believe what security by obscurity is.

"Security through obscurity" usually refers to systems which violate Kerckhoffs's principle.

The key point is that it is the system itself that is obscured, or which obscures something. Secrets may still exist within that model, such as a password or a cryptographic key, but they are secrets which can't just be discovered by reverse engineering the system. Obscure things can still be discovered. Security through obscurity fails because people try to hide secrets in a box, but then give the box to someone who has the ability to get inside it, and just hope they don't try.

Another way to look at it is this: you can make a password secret and build systems where only the user knows the plaintext password, but it's (mostly) impossible to build a useful system where the code or algorithm itself is secret.

In the end, though, your question really boils down to the difference in language between "obscure" and "secret". There isn't an easy answer to this, but I would say that the effort or leverage required to expose a secret is greater than that of something simply obscure.


Does an *additional* company-wide password offer any real security? So, let's say a company has what could be referred to as an "access key".  Each user has their own username and password, and there is an additional company-wide access key that people must input with their username and password to access back end resources.  When an employee leaves, the old password is removed and a new password is created and communicated to all users.

I don't believe such a scheme reduces security beyond a typical username/password combo.  It could guard against the scenario where a user's credentials have been compromised on some 3rd party website but are no longer sufficient to gain access without the access key.  It likely offers zero protection against a targeted attack, where it's probably simple to gain knowledge of the access key given its wide dispersal.

I guess my question is, can you think of any real increase in security this affords beyond the 3rd party compromise listed above, and do you feel the overhead of managing such a scheme is worth it?

You would be infinitely better off using certificates or two-factor authentication devices than a company-wide password.

The company password method suffers from the issue of key distribution (how do you get it out only to employees, and timely enough), people forgetting or otherwise losing t it, and wide distribution greatly increasing the likelihood of compromise. I guarantee you it will become culturally engrained to give that company password to nearly anybody or write it on post it notes all over the office as the pain of rotations is borne on people with a new password that they didn't choose.


What is the best way to encrypt my Windows user folder? I'm trying to encrypt my user folder on a Windows 10 shared machine.

I don't have Windows Pro, so EFS or BitLocker are no option. I can't encrypt or change the whole system since I'm not the only user.

I want to automatically decrypt and mount my files when I login, like what eCryptfs does on Linux (Ubuntu's Encrypted Home documentation is based on eCryptfs).

Does Windows provide any sort for supporting encrypted user folders ? Do you know of any examples of such a configuration?

Try to use DiskCryptor. I don't think it can encrypt folders but it's very good at encrypting entire partitions. You can simply create a partition and use it as a folder and encrypt it using this free tool.

https://diskcryptor.net/wiki/Main_Page


Best tool for testing an SSL connection in my application I have developed an application that send binary data between a .NET client and Java server via TCP.

I have recently implemented SSL for this connection and would like a way to demonstrate that it is actually secure for my college project.

What tools would you recommend? I've used Cain and Abel before but I don't think it is really suitable for this?

Thanks.

Openssl ships with a tool called "s_client" that can be used to test SSL servers.  This is available for *nix, cygwin, and Win32.

Sample Usage

$ openssl s_client -connect servername:port -CAfile /path/to/ca.pem -debug -showcerts

There are a myriad of options such as -pause, -state, etc. which you may find useful for tracking SSL through its setup and teardown.

Security

In your original question, you wondered if your implementation was secure.  By secure, do you mean that the stream is encrypted, or that you've implemented all aspects of the RFC correctly?  If you mean the former, then use Wireshark as D.W. has pointed out.

If you mean the latter, then check out the OWASP SSL testing page.  There's some great stuff there, but it is by no means exhaustive.  These tests are geared for HTTPS, but they should work for any SSL implementation since it is analyzing the SSL protocol, not the application-level protocol on top.


Has anyone else seen commands embedded in an ICMP echo request? My IPS recently detected a type 8 ICMP packet (echo request) with an unusual payload.

The echo request command a fragment of a command that looked like part of a route add. Here's a PCAP of the ICMP data payload.

.&.1Y..! .b....E.
..x..z. ...)....
....(4.. ......e
-p ADD 1 72.16.1.
21 MASK  255.255.
255.255  10.18.12
.33..... ..

The IPS tagged it as Loki tunneling traffic - but it's limited to a single packet. I thought it could be a random grab from memory, but I saw the exact same packet a few days later.

Has anyone seen anything like this before?

Ah, tunneling... SSH, DNS, ICMP, netcat, custom VPN... you name it. Sometimes known as "give me free wifi" and in other cases as "give me your network."

I don't know that specific payload (as a compromise), but I do know you can put things over ICMP. Take a look at the surrounding packets. This kind of reminds me of the old "ATH+++" gag. It may be a similar exploit for something that's being tossed around at random. I'd like to give more for an answer, but I think I'd need more to go on.


Nmap scanning computers behind a wireless modem Let's suppose that I have a router and three computers connected to Internet through that router.  When I tried to get the external IP address for each computer, I got the same address.  I think this is due to NAT translation.  I want to know how a hacker can scan a specific computer of the three computers using nmap and get all information about that specific one.

For the most part, you can't.  NAT acts somewhat like a firewall with a "default deny" rule.  Unless you set up a DMZ or port forwarding, a computer on the "internet" side of the router cannot make unsolicited contact with the computers on the "private" side.


Accessing encrypted data with multiple users I'm building a web based, LDAP authenticated password manager for internal use.

We don't want to store the passwords in plain-text in the database, and we want multiple users to be able to access the data.

My question is, how can we protect the data, whilst allowing different users using different login credentials? The only thing that comes to mind is storing the encryption key as-is, and then using logic (i.e. is user a part of a specific group) to decide if the app should use it or not to decrypt the data. This of course isn't safe since anyone with access to the web server would be able to retrieve the key.

Does anyone know of a way to achieve security like this when using an external method of authentication?

For each data record (or set of records, if the same users can always access all records in a set), create a random encryption key. Then encrypt a copy of this key with the key of each user who is allowed to access the data.

(The user keys may be either derived directly from the user's password using a suitable key derivation function such as PBKDF2, or you can generate a random per-user key from each user and encrypt it with the password derived key.  The latter option is a bit more complicated, but has the advantage that you only need to re-encrypt one key when a user changes their password.)

For more information, see e.g. this related question on crypto.SE.

Edit: I just noticed the mention of LDAP in your question.  I'm not really very familiar with LDAP, but as far as I can tell, if your application is acting as an LDAP client, so that the user enters their password to your application, which then queries the LDAP server to validate it, then you can mostly do it as described above.

The one thing you're going to have problems with is password changes, unless you can somehow get the LDAP server to notify you about them and to include the old and new passwords in the notification.  One option would be to have your app also check the entered password against its own database, e.g. by storing a hash of the user's encryption key (derived from the password with PBKDF2) in the database.  If the password passes LDAP validation but fails this check, it means that the user has changed their password, in which case you need to ask them to also enter their old password so that you can re-encrypt the data.

However, the ideal solution would really be to store the encrypted data (or at least the per-user keys) on the LDAP server, if the server can be configured to do that securely.  Based on some Googling, at least some of them can be.


Internal CA issues wildcard certificate Few of our web servers are managed by an outsourced partner who works as us in the same office, uses our laptops connected to our corp network, and has user accounts in our AD. They requested and applied wildcard certificates to make some of the IIS sites (all internal facing) https.

Someone in IT raised a concern that it is not advisable, from a security point of view, that outsourced admins request and apply certs on websites. Here is the argument:

  With a wildcard certificate you can "impersonate" any service, even the ones not managed by the specific team on the specific servers they have an agreement to manage.
  If the certificate is leaked outside of our company, it could pose a security risk, e.g. potentially be used to setup services pretending to be owned/validated by us when they are not.
  We may have NDA in place, but it would still be good practice IMHO to limit number of hands with access to certificates (I'd say even internal hands!), and considering that we even used pseudo-role based usernames as we expect that people may rotate more often than internal employees.

It is an internal certificate which wouldn't resolve on the internet. What do others think of this?

I'll supplement @schoeder's answer with some technical details.

My understanding of your situation is that you have servers applications like this:

intranet.xyz.abc.com
documents.xyz.abc.com
applications.xyz.abc.com
...

and your partner also has some applications running on the same server:

partner1.xyz.abc.com
partner2.xyz.abc.com

All of the above are internal-facing (not accessible from the internet). Now, the partner was too lazy to make individual certs for each of their IIS applications, so they made and installed a global a cert for:

*.xyz.abc.com

Cool. That covers all of their applications. But it also covers all of yours. Assuming they have access to the private key that belongs to this wildcard cert, then they can Man-in-the-Middle your intranet or documents servers and read all the traffic.

Also, if your company has (or a malicious admin with your partner decides to stand up) any public-facing websites that match the wildcard, for example:

www.xyz.abc.com

then, since it's a private internal CA, the general public would not be fooled by their spoof, but any of your employees connecting from internally (with that CA installed into their OS) would trust the spoofed version of www.xyz.abc.com.

As @schroeder points out, the potential for insider-threat here is huge.


Raspberry Pi IDS/FireWall - Should I? I was excited to setup an IDS/FireWall with my new Raspberry Pi on a standard home network. Reading threats to SSH and Linux, now I am not so sure. Setup by an experienced amateur I'm now concerned that it would turn an otherwise innocuous network into a DDoS and hacking target.

Yet ignorance is not always bliss, and I have no idea if my OS level firewalls are useful, and would like a practical means to protect and detect on my network.

For a home network is it better to rely on basic, pre-configured security and OS/ISP firewalls, or is there benefit to implementing advanced security via online guides/answers?

I think the worst case scenario is the machine is hijacked and instead of being a defense turns into a self-made MITM attack... is that accurate and/or are there more dire concerns (immediate - not dependent on the MITM concern)?

Yes, Please do it . It is still better than a network without any firewall. looking at the link, this is a simple network firewall with DHCP, DNS and SNORT. It does not decrypt your SSL traffic because it is not a Proxy. the Main function of this firewall is to protect your LAN from attacks (including some commonly known DDoS attacks as well).

as far as I know, the Linux network stack is pretty solid and there are some factory made routers running Linux as well.

SSH is called the poor man's VPN and is quite secure. use RSA with a key size of atleast 2048 bits or more(4096 bits even, if Pi can handle it) so that you don't get brute-forced.
 also, as the guide says, try signing the Host and User key with Certificates to make SSH more secure by enforcing Validation. Also SSH is not a requirement, you can have it turned off, if you don't want to connect to the firewall remotely.

  For a home network is it better to rely on basic, pre-configured security and OS/ISP firewalls, or is there benefit to implementing advanced security via online guides/answers?

There is always a benefit to implementing advanced security, like this firewall will detect tools like nmap used to survey the network, apart from filtering network traffic.

if you are just going to copy/paste whatever configuration is on that link without understanding why its done, then you are making a compromise there. another thing to be aware of, is that you might end-up blocking legitimate traffic, as most firewalls DENY ALL traffic by default. so, this is really a question for yourself on how much time and effort you are willing to spend on tweaking the firewall without affecting functionality.

  I think the worst case scenario is the machine is hijacked and instead of being a defense turns into a self-made MITM attack... is that accurate and/or are there more dire concerns (immediate - not dependent on the MITM concern)?

This firewall works in the network layer(mainly) of the OSI reference model. however most threats occur in the Application Layer and some of them can be quite dire. In a MITM senario, all unencrypted Text passing through the firewall can be read, however this firewall cannot decrypt SSL(HTTPS). So a compromised Laptop can be a much more dire situation than this compromised firewall.


What forensics should be collected as part of an incident response plan on Windows 10? I am in the process of creating an IRP that responds to system hacks.

I have attacked the Windows 10 myself (victim machine), using Metasploit on Kali Linux software, where I managed to gain access via SSH port 22. From there I have modified file extensions, accessed personal folders etc - on the victim machine.

As part of my IRP, is there any other useful area to look to prove an attack has taken place and files were accessed??
My IRP investigates (so far);

Windows Event Viewer (Application Logs, System Logs, Security logs)
OpenSSH log files

Any other alternatives would be very much appreciated.

Memory + Hoarder artifacts

Most guides want you to examine processes, network connections, and Event Logs. I don't recommend this.

Others, such as this great guide -- https://unminioncurioso.blogspot.com/2019/03/dfir-first-steps-with-volatility.html -- go into detail about timelines and certain registry hives, such as Amcache, that provide a unique view into what happened.

Perform an analysis using one of these as guest VMs after transferring your artifacts over:

https://www.skadivm.com
https://csilinux.com


Are there XSS vulnerabilities in the Vaadin framework? I am currently researching at some webapplication vulnerabilities especially client-side vulnerabilities like XSS. I have already read some topics about this issue. They said it was possible to inject malicious code inside XHTML.

But I would like to know how the current situation is like?
Is it still possible to use XSS for attacking the Vaadin framework? Could anyone give some code example for a simple vulnerability?

In case Vaadin is not vulnerable against XSS anymore - what would be (theoretically) a way to use a client-side vulnerability?

Ok, I found some interesting information about this issue:

  Vaadin has built-in protection against cross-site scripting (xss) attacks. Vaadin converts all data to use HTML entities before the data is rendered in the user's browser. You can explicitly allow HTML content in Vaadin components, in which case your application needs to ensure that the data does not contain XSS payloads. (official vaadin documentation)

So I tested some components for an XSS-Attack and behold... allowing HTML-content makes some components like Label,Tooltipand Notifications vulnerable against XSS-Attacks.

I have a sample code:

Label mainLabel = new Label("<IFRAME SRC=\"javascript:alert('XSS11');\"></IFRAME>");
mainLabel.setContentMode(ContentMode.HTML);
addComponent(mainLabel);


Hash, salt and best practices Reading about hashing, salt and pepper, I can't get my head around the following scenario:

If there's a web application and you register on that site, should the password be hashed on the client or server-side? If you would consider hashing it on the client-side, you also have to generate an individual salt that then is appended to your password and that combination gets hashed and then send to the server along with the salt or you could also hash the password, send that to the server and the salt gets then appended to the hash by the server, which is then again hashed. But if an attacker is able to intercept the connection between client and server during login, he's not interested in the salt, because the client just sends the hashed (or cleartext) password to the server... And if the attacker is able to break into the database, he's still able to bruteforce the hash. So as far as my knowledge goes, salts are only useful against RainbowTable attacks(?)

What's the best practice then? Who should hash the password and where should the salt be appended?

Generally speaking salts and hashes are done server-side, not client side. The communication between server and client should be protected with encryption (TLS).  As Anders mentions in a comment this may answer a lot of your questions: For an HTTPS web application, is it worthwhile to encrypt the password before POSTing it, to keep a MITM attacker from harversting it?

About salts and hashing in general: the idea behind salts and hashes often boils down to forcing the attacker to perform a brute-force algorithm.  This both (a) buys the service time to secure the network and change user passwords, and (b) prevents bad actors inside the company/website from acquiring the user's password (for naughty things like trying that password on other sites).

Salts do many things. (1) protects against rainbow table attacks like you said, (2) in the case of data breach, it makes password-cracking more difficult than vanilla hash (that is, there's no way an attacker can build a database of all hashes for an algorithm; they'd have to have that database for every hash, which is not feasible); this buys the site/users time to change the algorithm and passwords, (3) prevents people working for the site to be able to easily steal a user's password, and (4) grants more architectural options for securing the authentication process.

To talk about (4) for a minute, a (very large international) client of mine had a microservice architecture, and their authentication processes worked by hashing the password with one of many salts (based on username) before  sending it to the microservice which checked the actual database.  This type of separation prevented the code handling the database to know both salt and password, and the microservice which knew the salt would not keep hashes (neither in-memory nor on-disk). An attacker could not use a database dump; they'd need database and software from more than one server.  This increases complexity, as a stolen database gets them no closer to hashing the database; they'd also need the list of salts (from another server).  No employee had access to both servers, which helped with (3).

Why hashing client-side isn't super useful:
A man in the middle attack can capture whatever is transmitted between the client and the server.  Hashing the password before sending does very little; the attacker doesn't have to be able to generate the hash, they'd just have to send the exact same request again to get access.

For example, let's look the following requests and parameters (I'm not using real HTTP headers for readability):

POST /auth/login
user=me@example.com
pass=mypassword

versus:

POST /auth/login
user=me@example.com
pass=89e01536ac207279409d4de1e5253e01f4a1769e696db0d6062ca9b8f56767c8

The server can't know by the hash that the real password is "mypassword", so it'll just use the hash as-is to verify the user's account.  An attacker who can read that request doesn't need to know that your password is "mypassword", they just need to take the hash; that gives no protection for the account. The only thing this prevents is the attacker being able to test the password on other sites (eg, many people foolishly use the same email and password for google and their bank).


What mechanism enforces user permissions in Unix/Linux? One of the core pieces of security in Unix/Linux systems is limiting privileges by user. For instance, certain actions can only be done by the root user. In theory, this can keep a malicious process from causing too much harm.

But what mechanism enforces this?

As far as I know, there are basically two ways of password-protecting something:

Superficially: When Windows XP boots, it may ask for a password. Without the password, it won't let you log in, which might stop someone from accessing a file on the computer. But this only works if the attacker boots Windows; if they boot a different operating system and mount the hard drive, there is no protection on the file.
Cryptographically: Password management programs typically store passwords in a file. This file is encrypted with a "master password." Unless you supply the master password, the program not only will not, but truly cannot give you access to the file; it does not know how.

Which category do Unix/Linux user permissions fall under, and how is this enforced?

Linux user permissions are just a form of ACL, stored as data structure as part of the file system. They're enforced by the operating system, but not in any solid sense - a file system driver or OS that doesn't recognise Unix-style permissions will just ignore them. The same goes for Windows file permissions, which are ignored on Linux systems.

Transparent file-system encryption is done via a key stored in the users database, which is in turn encrypted by the user's password. When the user logs in, the password is used to decrypt the key, which can then be used to decrypt the file data.