Is it secure to store encryption key (encrypted with master key) with the data it was used to encrypt? I am working on a password sharing web site. I would like users to be able to enter their credentials and share them with other users. I am thinking about using KMS service to store master key (just one) and have a database to store key - credentials pairs. User's credentials will be encrypted with the key from the database and the key stored in the database (different for each credentials) will be encrypted using KMS master key. AES encryption algorithms will be used for both: encrypting user's credentials and encrypting the key used to encrypt the credentials. Would it be secure enough to store encrypted key along with credentials or is there a better approach?

The real question to ask is "what is your threat model?" What sort of
  attack are you trying to prevent? Are you creating a digital lock on a
  diary to keep it safe from your sister's prying eyes, or are you
  Edward Snowden, on the run from several three letter agencies with
  billions of dollars of funding? AES-256 is currently labeled as
  sufficient to use in the US government for the transmission of TOP
  SECRET/SCI information. That's pretty much the highest classification
  level they could clear it for, so the US government is pretty darn
  confident that nobody can break AES-256 on the timescales required to
  protect our nation's greatest secrets. (Well, almost. What it really
  says is that they are confident that nobody outside of the US
  government can break AES-256. What you believe that that says about
  whether the US government, themselves, can break it depends on your
  threat model... and whether you engage in discussions of whether
  heavy-duty tin foil makes better hats or not)

Reference

AES key encryption is secure enough for keeping the data safe. In my opinion if the master key M is compromised, it can lead to decrypting all the key X. If you use a public key encryption to encrypt key X, only a partial of the data would be compromised. Say for example, there are two users U1 and U2, and there public keys be PubU1 and PubU2, private key be PriU1 and PriU2.

When U1 want to share his credentials with U2, the application uses PubU2 to encrypt the key X, so that when U2 want to access the data he will first decrypt using PriU2 and then uses key X to decrypt the data.


Passing a hash of a secret to a server instead of the plain text Instead of passing an authentication token or api key in an http header to a server in the plain text, what if I calculated its hash and passed the hash? This way even if a adversary intercepts the hash, it'll be useless for them. And a server can easily calculate a hash of the real password on its side as well and then check if they match. A salt can be added also.

Will it work? Is this approach widely used?

No, this approach is not widely used and here's why:

If the client hashes the password and sends this to the server, then doesn't that hash become "the password"? As an attacker, can't I just intercept the hash and use that in a replay attack?
You said "A salt can be added also". This one actually is done in some protocols, when you add in a random value to make the hash different each time, it's called a nonce.
Most importantly, the server knows the plaintext password!? Bad Idea! If your server knows the plaintext password, that means it is storing the plains in a database, that means a database breach leaks all your users' plaintext password. Only storing password hashes in the db protects you against this. Are you really willing to risk a total and complete breach in order to make your protocol a little bit simpler?

Bottom line: I'm happy that you're thinking about protocol design from a security perspective. I would encourage you to have a look at the TLS handshake because it is a very well thought-out protocol that uses a lot of the concepts that you're thinking about.


How safe is it to store your passwords in a modern browser? There's a few questions here along these same lines already, but they're nearly a decade old. I'd like to know if things have changed, especially now that Chrome has become more aggressive about asking users to save their passwords, and those passwords being associated with a cloud account.
There's lots of rants against Chrome's current password saving policy, and lot's of articles warning against it. However, I don't know if I agree with them all.
Some obvious observations:
Against

If someone gets physical access to your machine, there's only the OS password between them and every password you've ever saved.
Someone could potentially hack into your Google account, sign into Chrome, and also get access to all your passwords.
There's no "master password" (outside of your OS password) to protect them if someone should get logged in access to your computer.

For

According to HaveIBeenPwned I have had my email address and passwords shared online dozens of times thanks to hacks to websites. (Including big companies like Adobe, LinkedIn, Kickstarter, etc. and that's just the known hacks.) In that same time I've never had a computer stolen or been subject to a physical security breach.
If I use a uniquely generated password on every website, and save them into Chrome, no other websites accounts will be made vulnerable from another website security breach.
I probably trust Google to detect and protect me from unusual activity more than almost any other online service (which isn't to say they're infallible, obviously).

In terms of attack vectors, it seems that if you feel you're more likely to be open to a physical attack (or attack from someone you know), then saving passwords into a browser could be a very bad idea.
However if you're more likely to be susceptible to remote attacks by strangers, then having unique passwords stored on every website is likely to improve your personal information's security. (In any case that would obviously be the ideal, but security has to factor in practicality - and the average user isn't going to remember a unique password for every website.)
(I wonder if a better solution to Chrome's current one (which allows users to reuse easily guessed passwords across websites) would be to force (or encourage) the user to only save unique and complex passwords?)
What are the pros and cons of real-life scenarios? And is there any situation you would ever tell a user to save their online passwords in their browser?

Not as good as a password manager, better than nothing.
Security often comes at the price of convenience, and convenience often comes at the price of security. Password managers built into browsers are primarily there for convenience, and security plays a lesser role. The reason for this decision is that regular users are more easily convinced to use a system that is convenient for them, rather than a system that is more secure, but harder to use.
Since you asked for Pros and Cons of real life scenarios, I'll detail the pros and cons of using a browser's built-in password manager in comparison to an offline password manager like Keepass, and not using a password manager at all.
Using a browser's built-in password manager:
Pros

You already have it. Everyone uses a browser these days, and all major browsers come with built-in password managers. This means that from a regular user's point of view, the barrier to entry is incredibly low.
It discourages password reuse. People dislike remembering passwords, so they certainly won't remember one password per site. If the browser automatically suggests a strong password upon registering, then the user will not be tempted to re-use an existing password for it. Furthermore, the passwords suggested by the password manager will likely not be cracked by any attackers, should hashes ever be stolen.
It syncs to my other devices. A user can register to a service on their computer and then use the same service on their phone without having to worry about syncing passwords. That is a huge plus!

Cons

It doesn't defend against local attacks. Attackers which may have access to the computer of the user (think jealous girlfriend, not government agency) may be able to get the passwords rather easily. With access to the browser, for example when a user forgot to lock their computer, all passwords can be read out in a matter of minutes.
It should be noted that local attacks are not something every user is concerned with. For example, I am living alone and don't really have local attacker in my threat model.

It increases attack surface. If synchronization between devices is enabled, then the security of all my accounts is tied to the security of the account of my browser vendor. Furthermore, while it is unlikely, but not impossible, an attacker could steal the encrypted credentials of all users and then begin to crack them bit by bit.
Since my passphrase is 72 characters long and I use a YubiKey, I am not all too worried about people logging into my Google account - but it could be a reason why you wouldn't want to enable synchronization.

Vendor Lock-In. To my knowledge, browsers don't yet offer some way to export all credentials into some unified format. This means, if you have 200 credentials saved into Chrome and decide to switch to Firefox...well, have fun.

Using a dedicated offline password manager:
Pros

Better protection against local attacks. Since passwords are stored in an encrypted file, which is protected by a master password and optionally a key file as well, an attacker with local access will likely not be able to steal your passwords. In the case of you forgetting to lock your PC, many password managers have settings to "forget" the key after a period of inactivity. While that doesn't completely protect you, it is much better than a built-in password manager.

Better configurability. A browser's built-in password manager may struggle with sites which have less than desirable password policies, so a dedicated password manager can generate passwords according to a specified ruleset.

Works outside the browser. Sometimes, I need to generate passwords to send via other means, such as text messages, or use them inside a VM. In this case, a browser's built-in password manager just doesn't cut it.

Cons

Higher barrier to entry. Users which don't have a background in security are unlikely to look for a password manager, and if they do, they're likely daunted by the different offers, such as online password managers, offline password managers, etc.. Furthermore, most offline password managers have quite a few very handy features, which are likely confusing for someone who "just wants to use the internet".

Doesn't sync between devices. Since my passwords are just a file, it doesn't automagically sync between my devices. If I have a desktop PC, a laptop and a smart phone, then either I manually sync my password database between them, or I use some third-party service to do that for me (like Dropbox, Google Drive, etc.)

Not using a password manager:
Pros

Works everywhere. Often times, I need to enter some form of authentication where I simply can't use a password manager, such as for my BitLocker password or my Windows domain password. In such cases, remembering a strong passphrase is the only option I have.

Cons

Encourages weak passwords. I won't remember a password like _B+5ZzRk!4vd2+5Q?qw$=9V, that's a fact. I may remember a long passphrase, such as Two Blue Bunnies jump over the Square Tree and Explode., but that's quite a handful to type every time I want to log in. As such, most users will gravitate towards the shortest possible password they deem "good enough", and usually that's something like BostonNovember2020.

Encourages password reuse. "I already thought of a password or passphrase, and now you want me to remember a second one? A third even!? What do you mean I need to remember a new pass phrase for every service I use?!" - That's why people re-use passwords.

Verdict
Dedicated password managers are a great high-security option, that offer a ton of configurability. However, as many tools aimed at experts, they can be difficult to use for beginners.
Built-in password managers strike a good middle-ground for non-tech people, increasing their security against likely threats, while making them a bit less secure against unlikely threats.
Using no password manager at all should only be used in situations where no password manager is available.


Set up an AP that indicates it is encrypted with WPA2 but in fact is open? I want to create an exact duplicate of an existing access point that use WPA2 AES (CCMP) for encryption so that the clients will automatcally be connected to my AP, so I used this command:

airbase-ng -c 11 -W 1 -Z 4 –essid MyFakeAP monO

However the clients throw authentication errors. What am I doing wrong, or is my idea even feasible?

What you're seeing is the intended behavior. Clients won't be able to connect to your rogue AP as your AP isn't set up with the same PSK the real AP is, and clients shouldn't connect to a network that has the same name (SSID) but different security (unencrypted).

To answer your question, no it is not possible. Even if you manage to set up such an AP (pretty much impossible as the low level parts of Wi-Fi are handled in the NIC's firmware, so good luck getting that firmware to advertise it's broadcasting an encrypted network while in fact it isn't), the clients wouldn't be able to connect as they'll still try authenticating and will obviously fail because your AP won't be expecting the authentication frames as it's broadcasting an unencrypted network.


Is there a way to protect against fake messages by an SPA that consumes a webservice directly? I develop a webservice currently and communication might be a bottleneck. It would be at least 100ms faster if I could access the webservice from the browser directly instead of sending the messages to the consumer's server first and relaying them to the webservice along with the consumer identifier.

If I store that consumer identifier in the SPA, then everybody could fake a request in the name of the consumer, they just need to check what the SPA sends to the webservice as an user of it. Is there a way to protect the webservice against these kind of fake messages?

Edit:

Sorry, I forgot to add important details:

The webservice is not typical, I don't have a main site like facebook, all the users are registered to the webservice through consumers who will need the service to earn money, so I guess they can be trusted more or less, but somebody can add a consumer if they pay the price and can start to hack the system as a consumer. So the question does not have anything to do about allowing an untrusted 3rd party client to access the profile page, photo albums, etc. of an already registered user e.g. with oauth.
I send the user credentials (or auth token) with each message, so user identification is not a problem.
Reusing registrations among consumers would be a nice feature, but I am not sure if it involves security issues.
I'll write some of the clients in the beginning, but if the service grows big, I won't be able to check the code each of the clients, so some of them can contain vulnerabilities.

I think a real threat would be somebody who gets some of the consumer ids and user credentials e.g. with a fake login page and starts to send messages to the webservice in the name of different consumer and user combinations. If I make the consumer ids public, then that would be a lot easier to do. I don't know what I could do in such scenario, how to separate the fake from real messages, etc. so it would be nice to avoid that scenario or have a plan for it, or both. Ofc. an attacker could use the client of the consumer instead of sending fake messages directly, but that feels something easier to control. I don't know why, I need to think about this a lot more...

Just to be clear, your scenario is:

You have a web service, which requires authentication to use.
Your customer has a web app, the server of which acts as a client of your web service.
You are looking to allow your customer's users to interact with your web service directly having their browsers act as the client (presumably via CORS request).
You want to prevent your customer's users from making arbitrary requests to your web service using your customer's authorization.

Is that all correct? If so, you're in a tricky spot. Broadly speaking, that is of course impossible; any request a web app can make, a user can open the browser's developer console and re-play, tweak, read the result of, etc. Anything the web app can add for authentication or authorization - headers, cookies, secret tokens or HMACs or whatever - the user can tell the web app to add to their own message.

There are things you can do that might be sufficient in this case, though. You can have your customer give different authorization tokens to each user (assuming your server can validate them all), so that if some user abuses the service you can tell who. If you're worried about too many requests flooding the server, you can throttle requests by authorization token and/or source IP. You can scope the customer's authorization down to only APIs and data the customer needs, preventing the users from making actually arbitrary calls. You can even combine that last option in a hybrid approach; users receive a token that can make some low-risk calls directly, and all others have to bounce off the customer's server.

More specific advice would require more information about what you are trying to secure, and why. In general, though, there's no way to tell whether a request comes from an authorized client or somebody who is misusing (or cloning) that client, and that's especially true when the official client is a web app.


What exactly is the impact on security when forcing user passwords to contain a particular character? Some years ago a sysadmin of large computing centre (on a campus) enforced the password of every single user to contain the character $ at an arbitrary position. They soon dropped this policy but I always wondered what could possibly be gained by this. Would this actually make passwords more secure or would it make them weaker?

Letting aside the human factor this would have on the memorability of passwords, my assumption was that this would have no effect on how it is to break a password since it is known that one of the characters is $. However, given that the position of the character and the length of the password were arbitrary, maybe there is more to it.

Can you shed some light on the effects of this policy and why anybody would enforce it?

You are basically reducing the overall entropy of your password, as one of the characters will always be known.

This effect is further amplified by the fact that most humans are predictable creatures. If you force them to place an arbitrary character somewhere in their password, there is a high chance that character will be the first or last character in the password.


What can you do to make a hashed token database retrievable at a later date? I have a table for single use tokens, and one of the columns is a token_digest which contains a bcrypt hash of the access token. Since the token_digest is a salted and hashed version of the plaintext token, I can't just run a select against the computed hash.
When my application gets the plaintext token from a client, how can I find the correct token record from the database?
The only way I can think of solving this is by adding a prefix to the token that is stored in the database and isn't hashed. So you'd have something like prefix9581d7b867eb0fe0da59fc98faa27fb8. Then you can find the token in the database by issuing a select with where prefix = 'prefix'. Is this incorrect or an insecure solution?

What use case do you have for not having a token ID ?
Anyway if you use long random tokens (having sufficient entropy), then both bcrypt and salt become unnecessary and you can speed up operations by using unsalted SHA2. With the same premise your proposed solution is also acceptable, though it seems unnecessarily complex.
(edited after comments)


Question about saving credit card info on PW reset [PCI] I work for a retail organization with a large ecommerce presence. We allow our customers to store CC information for easy check-out, like many retailers.

Currently we remove all stored CC information upon Password Resets for an individual. There is a request by one of our business partners to change this and retain CC information through the PW reset. To clarify, when the PW is reset, an email gets sent to the users primary email address with a link to reset the password.

The justification for retaining it was that it's an inconvenience today, and we are seeing lost sales due to consumers not re-entering their CC information; in particular, our co-branded and store cards.

If there WAS a malicious user who had access to credentials for our web site, that user would simply log in as the target instead of reset the password. If the user has access to the email address on file to complete the password reset functionality then we assume that it's indeed that person and not someone maliciously trying to reset the password, hence the request to retain CC information.

I am wondering if this has any sort of PCI implications that could land us in hot water?

I understand the reasoning but want to make sure we are doing the right thing.

I am wondering if this has any sort of PCI implications that could
  land us in hot water?

None that you're not already dealing with.

PCI cares deeply about how you store PAN (Primary Account Number) and related information.  If you are storing credit cards, they need to be securely encrypted, and the machines they're stored on require certain security measures, and the network they're transmitted using requires certain security measures... when you store PAN, you're signing up to do a lot of security and auditing work.

That is true whether you're storing them for a day, a year, or any period.  If you expunge a user's PAN data every 3 months when they change they're password, your obligations are no different than if you don't expunge it.

(Tokenization - probably offered by your Processor - can reduce the scope which you have to protect, because you aren't storing the PAN personally.  However, it doesn't make any difference for your concern; a non-expunged token remains usable after the password reset just as a non-expunged PAN would)

Personally, I don't know that I've used a merchant who requires full PAN re-entry after a change, although re-entering the CVV I have seen.  You may be able to find alternatives (re-enter the CVV; answer a Security question; ...) that are less intrusive ways of being extra careful following a password change.

(To be clear, the point of asking for the CVV is to use that during the credit card auth as an extra validation, not to compare it to a previously stored value - DSS doesn't permit you to store CVV between transactions.)


security updates for embedded firmware Tomato (router) I installed on my Linksys router Tomato firmware.

I saw

and now don't understand how security updates work. It can't be that there is no vulnerability since 2010.

Tomato Firmware v1.28.1816
Copyright (C) 2006-2010 Jonathan Zarate
http://www.polarcloud.com/tomato/
Built on Sun, 27 Jun 2010 20:10:52 -0700

Development of the official Tomato firmware has indeed been discontinued since 2010 with version 1.28 being the latest release.

Wikipedia has a nice comparison table of various forks that have been created since then. Although it has a focus on Linksys routers, you can find current information on actively developed Tomato mods in this forum. The AdvancedTomato firmware (a fork from Shibby mod) is one possible option with fairly frequent updates.

That said, I find it suspicious that Tomato seems to have a very short record of publicly known vulnerabilities. This could either be due to well-written code or indicate that there has not been a lot of auditing since then.


Cyber resilience scoring What would be good assessments of cyber resilience? I imagined something like a score on different topics e.g.:

Data Protection: HIGH RISK
Malware defense: MEDIUM RISK
Application/System Life Cycle: No RISK
Vulnerability management: EXTREM RISK

etc.

Where the risk assessment is the result of subcategories like:

1.1 Backups in place?

1.2 Data Leakage Prevention?

1.3 Assess control effective?

or

2.1 Anti virus installed everywhere?

2.2 Anti virus definitions up-to-date?

2.3 Office macros disabled?

My Question: Is there a standard for such an assessment? I looked at the ISO 27k series, the french ANSSI, the german BSI or the OWASP Project, but i could not find such a metric. These documents seem to be not technical enough to define a measurable checklist.

For example the very helpful document http://www.ssi.gouv.fr/en/guide/40-essential-measures-for-a-healthy-network/ contains 42 security measures.
However, i find it difficult to create a scoring function out of it.

You are not going to find a standardised metric because that's not how risk works. Figuring out how adverse events will have an impact is the whole point of risk management.

What would present a risk to a major university will be vastly different from what would present a risk to a 3-person app development start-up.

For instance:

  2.1 Anti virus installed everywhere?

For a small company that only uses Chromebooks, you can't install AV. And it doesn't matter.

For a university doing sensitive research, you could install AV on the research computers, but then the type of AV might send files to Russia, or the AV might interfere with the proper running of the analysis software. Installing AV would actually increase the risk instead of reducing it. The risk that is meant to mitigate is that malicious code could be run on a device. AV is just one control to mitigate this risk, and each control can present its own new set of risks.

I'm afraid that there are no shortcuts in risk. You need to understand the adverse events on your people, data, and technology and what impact they might have.

For broad strokes, there are frameworks that rank various controls against each other in general terms.

As alnbhclyn shared: CIS Top 20 Critical Security Controls has 3 broad categories of control maturity
Cyber Essentials presents a collection of controls in 5 broad categories that the NCSC feels are the most critical to mitigate 80% of the most common cyber risks

You might also look at the NIST CSF that breaks down 108 different activities into Identify, Protect, Detect, Respond, Recover, and you can score yourself on whether you are doing those activities and where you are weak. Be sure to go through each activity to determine how relevant they are to your organisation.


Transport Layer Security for multiple persons I know that TLS protocol is used to authenticate two persons and when a secure channel is established we can perform a key exchange.

My question is if TLS can be used to establish a secure channel between more than two persons. If yes how?

TLS requires an out of band mechanism from which to bootstrap trust between the communicating parties.  Using an external certificate authority is one approach.

an alternate approach is PGP's web of trust, where individuals you trust sign the public keys of individuals you don't yet trust.  Here, Alice might connect to Bob. Alice trusts Bob. Bob connects to Carol, whom Bob trusts. Bob tells Alice Carol's public key and address, and tells Carol Alice's key and address . Carol and Alice can now connect to each other, based on trust in Bob.

Alternately, Alice and Carol can exchange keys and addresses in person, such as on business cards.  They can then contact each other, believing that they are talking to the person they met in person.

Or you can have a central server where each user has registered a public key. Any other user can connect to the server and ask that server to forward traffic to the recipient as known by such server.

Edited to add: please don't design your own protocol.  See the following link for a discussion of why not: Are there any holes in this security design?


Does Windows keep an Active Directory user token while locked? The Firewire DMA hack Inception allows for the password checking subroutines on a local Windows box to be overwritten, allowing any password to be entered for a locked computer.  My question is about the impacts of this on a networked system.

When logging in to an Active Directory controlled system, the system is given a token that it can use to gain access to network resources for the user without the user having to re-enter their password.  Is this token kept when locking the system or reacquired when unlocking?

I am trying to better understand the possible risks of an Inception derived attack on a corporate network.  If it only allows access to the local system, it is significantly less of a risk factor than if it is also able to gain access to network resources associated with the user.

Honestly, I don't know. What you could do is log in to a computer requiring a network connection to log on (no offline profiles), make some test connections to show that the token is working. Then lock the computer remove the network connection and log back on. Turn off your domain controller, and If you cant get onto any network shares then the computer had to re authenticate to the controller.


how to check which data can be read from you? I want to know, how much I tell "the internet" about me via my browser. E.g. there are test sites that can read your IP. Is there any security site which trys to read all possible data from my browser?

E.g. I want to be sure that no one can easily "hack" what eg. email adresses I use and possible more dangerous: Is there enough big data of my person that someone can relate an email adresse to my real name (from an other online account)?

Assuming you don't use any particular browser and stick to some of the popular ones (such as Google Chrome or Apple Safari) you tell to the Internet a lot of things, at least the following,

IP: assigned to you by your ISP and so linked to the ISP's subscriber's service
Browsing behavior: to the browser's vendor, possibly some details as well to the OS vendor
Tracking details: to the website you are visiting (cookies), to invisible (and embedded) tracking software, to the advertisement software that allows for these in the website you may be visiting, to other third parties that may be providing some service for the website or your browsing (Adobe Flash...)
Browser fingerprinting: you would be surprised how unique it is to you (could be in the previous category of tracking, but it is worth its own category)

Moreover, there is the part of your personal information, anything you give can be used to track you. Although in some cases it is necessary, such as logging in some site to uniquely identify you.

As said by @J.A.K. it is about linking information, but there is the part of those who know you and provide details about you, something that you have little to zero control, and this can also be used to track you and eventually identify you as well (think of someone mentioning a nickname you use in some website that you registered).

@Alpha3031 pointed at a couple of interesting test sites of such browser fingerprinting and tracking within a site.

You may want to use TOR and browser the web via the TOR browser (https://www.torproject.org/projects/torbrowser.html.en). It will reduce your footprint at the expense of a slower browsing, and possibly degraded user experience if you are really committed to minimise any leak of information of your browsing habits.


Why does Spring Security unset and set the same Cookie in one Request? In the CSRF implementation of Spring Security (https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/csrf/CsrfAuthenticationStrategy.java#L57) they first "delete" the XSRF-TOKEN-Cookie (Line 58) and directly after that they set a new one (Line 60).
This leads to two Set-Cookie Header on the same requests:
Set-Cookie: XSRF-TOKEN=; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/abc
Set-Cookie: XSRF-TOKEN=35ed383f-4ea1-4e00-8e5d-9bc9a3740498; Path=/abc

Can someone explain why this is done in this way?
Is this a common pattern?
Are there any problems with browsers as they got two Headers for the same Cookie?

It looks like it's just a bug.
By looking at the history of the function onAuthentication, we can see that the first implementation only had the line:
this.csrfTokenRepository.saveToken(null, request, response);

Then, it was refactored by adding:
CsrfToken newToken = this.csrfTokenRepository.generateToken(request);
this.csrfTokenRepository.saveToken(newToken, request, response);

The first line with saveToken(null, ...) was never removed, despite serving no purpose.
In a comment, AlphaD pointed to a comment on a github issue explaining why the first line was kept:

it is first invalidating the cookie and then setting the cookie. That is expected if you log out and then try and use a token

Which should not be needed because the second Set-Cookie: should overwrite the previous cookie, thus invalidating it. In fact, this "obvious" behavior is not specified, so browsers are also free to discard the second declaration of a cookie with a conflicting name, which would break the expected behavior by the Spring developers.
Indeed, RFC6265 asks not ot use to Set-Cookie: with the same cookie-name (here XSRF-TOKEN), so this behavior is a pattern that is explicitly discouraged:

Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name.  (See Section 5.2 for
how user agents handle this case.)

Since this pattern should not happen and the RFC does not provide further recommendations, browsers are free to interpret it how they wish. Compatibility breaks with some browsers could happen at any time if they update their algorithm.


Securely hide a directory from the OS using java? I have a project to do for my master's degree and I need to do a Java app which loads a file (read some attributes and copy the file to a working directory), basically any file, and make the working directory private. By private I mean to hide that directory in a way from any OS (well, basically Windows and Linux). I'm not sure that the OS (Windows and Linux) functions to hide directories work because an admin/superuser can modify those settings and easily access my files.

The idea for the project is to have exclusive access to those loaded files from within the app and to make them available for the applications installed locally to open/run them (like "Open in media player"), which should work also when I copy the app to a USB stick.

I have 2 options:
  1. modify each file after loading to make unreadable to the world and undo the modifications each time I press "Open" from within the app;
  2. (which I think is the best and most simple option) Modify the root directory of those files (root = the working directory or some subdirectory of it) to be unreadable/unaccessible to the world while outside the app and readable to the app at  runtime.

I've been thinking about something like making a locally encrypted copy of filesystem attributes of the directory, "delete" them while not at app runtime and put them back while at app runtime. But I haven't really played with this before and also Windows & Linux filesystem aren't simple at all. More of it, a USB stick has a FAT filesystem (which if I'm not wrong "belongs" to DOS), which is, yeah, another filesystem into the equation.

I'm almost sure it is not feasible (and not secure!) to simply play back and forth with the filesystem at my pleasure, so I need some ideas to find that breakthrough without actually breaking anything.

One trick you can use in Linux is to create a file, keep the pointer/handler and delete it immediately. You can then use your file's handle to write and read to it. Linux won't show the file to nobody because you removed it from the OS's file table. Unfortunately you would have to write back the file in a "normal" file when you program closes since you did delete the file. This method is usually used to create temporary files for programs.

As for windows I don't see how you can manage that.

Hope that helps a little.


How can I allow access to encrypted data if only 2 out of 3 users provide a secret? I want to encrypt data, but make sure that no single user can decrypt the data.

Further, it is important not to require ALL users to be present to decrypt. This will allow for some flexibility and reduce the consequences if/when secrets are lost. It should be enough that 2 out of 3 secrets are provided, or a configurable fraction with a larger number of users.

Does this kind of security scheme exist and have a name? If so, how is it typically implemented?

It is called threshold encryption (or, here, decryption).

A well-known scheme is Shamir's Secret Sharing. It allows splitting a secret value into n shares, such that any t shares are sufficient to rebuild the secret. n and t can be chosen at will (although you will want to have n greater than t in practice). For the threshold encryption problem, you apply Shamir's scheme on the decryption key. When t share holders meet, they can rebuild the decryption key, and then decrypt the data.

Though Shamir's scheme is fine (in fact, it is provably secure even against attackers with infinite computational abilities -- very few cryptographic algorithms can claim to be similarly secure), it has a limitation which is the following: it rebuilds a secret. This makes it somehow "one shot": if the share holders rebuild the secret, then they have the secret. Each of them will be able to do further decryptions alone by simply remembering the rebuilt secret.

Depending on your context, this may or may not be a problem. For instance, there are voting systems using homomorphic encryption (e.g. with ElGamal), where the encrypted votes are tallied together without decrypting them (that's the point of homomorphism); but the final count must still be decrypted. We want threshold decryption here: several authorities must collaborate with each other to do the decryption. That way, the authorities keep each other in check. However, if they learn the private key itself in the process, then each authority will thereafter be able to decrypt individual votes, which defeats the whole purpose.

If this issues apply to your context, then you must do more mathematics. There are threshold decryption schemes which allow, for instance, a threshold ElGamal decryption, such that t share holder must talk to each other for each decryption instance, exchanging "partially decrypted messages". The private key is never really rebuilt, but its action (the decryption) is gradually reproduced.

There is a lot of theory on threshold cryptosystems, with various characteristics (how many shares, what possible threshold values, does the scheme resist well when some share holder actively cheat, how many messages must be exchanged, and so on). If your problem at hand can be solved with Shamir's scheme, then, by all means, go for it. It is reasonably simple to implement (in particular, sharing files is easy if you do all computations in GF(28)).


Methods of determining if a software bug is a security risk? I don't really want to get into the specifics.

I found a bug from a huge software provider. As any other responsible user, I have reported the bug to the software provider.

It is hard to tell if this bug would be considered a security risk or not, as it doesn't directly compromise security. However, I could most certainly see this as a vector to "dig deeper".

Regardless of my findings or interpretations of the bug, it got me thinking: How does one systematically determine if a software bug should be labeled as a "security flaw"?

The methodical approach  to this is to go through a standard software security framework such as  OWASP Software Assurance Maturity Model (OWASP SAMM Project) or BSSIM or any other other standard Software Security Maturity model. You need to properly identify the things such as Threat agents, Attack vectors, Security weakness, Security controls, Technical impacts and Business impacts of your identified bug in terms of security.

Then you need to model it using a Threat model framework and rank your identified bug. There are numerous threat models such as CVSS , DREAD, STRIDE. Finally you need to identify the ROI of the effort you need to put to resolve this issue. The business would use the values returned by your model analysis and give a go or no go to fix the issue.


Is HMAC preferable to Digital signature I'm new to infosec.
I'm studying about various encryption algorithms.
Based on what I've found so far, I think HMAC and Digital signature are almost the same except whether the key is symmetric or asymmetric.
For me, it seems that a complexity of HMAC is lower than the digital signature according to its function. Then can I say using HMAC is preferable to digital signature?
I found that the weakness of HMAC is the key getting compromised. But does it really happen? if so, how does it occur in the real world?
+ when digital signature is more efficient than HMAC?

They're suitable for different use cases. Assuming you're using a well-tested implementation written by somebody who knows what they're doing (so, probably not something you wrote yourself or pulled off some random person's GitHub), they're both quite secure, although the threat models are a little different. Also, HMACs are generally computationally cheaper.

HMACs are only usable when you have complete trust in both the party certifying the message (usually the author), and the party verifying the message's authenticity. Complete trust is required because the ability to verify an HMAC also means having the ability to forge one. It also only works when you have a secure way to exchange the shared key.

Signatures are used when the party verifying the authenticity is not fully trusted by the certifying party, or when there's no way to securely exchange keys. It's usually more computationally expensive and requires storing/transmitting more data, so it's usually not used unless needed.

HMAC key leakage is mostly a problem when "fully trusted" is a little fuzzy. For example, you might trust a third party to not forge messages, but do you also trust them to have adequate storage of the key and adequate protection against application compromise? Or perhaps you trust their key exchange system to be secure against an attacker intercepting or tampering with the exchanged key, but don't trust them not to capture it in a log file somewhere that might later get leaked?

There aren't many situations where you really have to choose between the two constructions. The main one that comes to mind is the JSON Web Token (JWT). My usual advice for JWTs is that if the party verifying the JWT is meaningfully less trusted/trustworthy than the party generating the JWT, use a signature; otherwise use HMAC. However, it really should be decided on a case by case basis.


Should an IT Security Policy allow employees use public Wi-Fi? Should an IT Security Policy allow employees use organisation-owned laptops holding potentially sensitive data access public Wi-Fi in locations like hotels and airports?

Wi-fi traffic can be intercepted at will. It's essentially a broadcast, in the clear in open wi-fi, or encrypted with the password if one's present; most of the time, even that encryption is insecure.

Public wi-fi is generally unsecured networks or networks with a shared key. This allows an attacker unfettered access. A typical traveler won't know which of the many appropriately-named networks in the airport is official, and which is an opportunistic attacker. So it's a safe assumption that the traffic routinely sent through open wi-fi networks will at some point, in some network, eventually get intercepted.

As to whether it's a security problem, in the perfect scenario where the sensitive data just lies on the drive, preferably encrypted, the user is not an admin, they only use the wi-fi for their personal needs, never to send sensitive mail or access company data, and they use encrypt&authenticate all their traffic, it's not.

In the imperfect real-world scenario, where sensitive and personal data is mixed up, the users alternate between using their laptop like a workstation and like a public terminal (disregarding security, since they're "just checking the weather"), it is. You'd be trusting several human-dependent protections for security, the breach of even one of which will leak the data. Worst-case scenario, the user's laptop can get a RAT (remote access trojan) uploaded to it.

It's not an automatic security fail - much of the web uses SSL now, so it's not like everyone sees everything, and VPN traffic can come through encrypted as well. But it's a large attack surface for a dedicated or opportunistic attacker.

The best solution is, IMO, to ensure the laptops used for travel aren't holding sensitive information, and aren't plugged into the vulnerable parts of the intranet (assuming zero-trust is not in place). On top of that, ensure the personnel on travel follows at least a minimum of security practices, such as not using open networks and not mailing sensitive data without end-to-end encryption.

If it's absolutely necessary to transfer sensitive data beyond mail to and from laptops while traveling, it's possible to design a corporate network that's secure over insecure channels, but it takes considerably more security expertise to set up and keep secure than can be realistically covered in a SE answer. The VPN has to be secure and always up, the laptops have to reject all other connections, including for Windows update, there shouldn't be any ways around it, and so on.

Given the negligible cost of local SIM cards compared to the expense of business travel, it's best to use them in favor of public wi-fi, together with other security measures (encrypted mail, encrypted files, low privileges, compartmentalization, monitoring, VPN). Even secured wi-fi is still someone else's network, someone local that can be impersonated and that gets two-way access to your traffic.


Can someone send a text to a phone and make it appear on another person's phone text message? A friend said her husband was sleeping on the couch, and she got a text that appeared to come from his phone, but he didn't send the text.  Is this possible to do, and, how can she trace the origin?

The text that she got on her phone showed up on his text screen on his phone as well.

The origin of the text could be an application that has the privilege of sending SMS from the owner of the phone that it's running on and reading the phone's contacts. I suggest looking through applications on the phone in the systems menu and determining what the privileges allowed for each app is, especially newly downloaded or newly upgraded apps.

If you find an offending app with privileges that you don't want it to have, either uninstall it or revoke the privileges you don't want it to have and be more careful next time when installing outside applications on your mobile device. Always read the list of permissions that an app is requesting on installation AND when upgrading.


JtR Password hash not recognized I am attempting to encrypt some passwords by hand to use in a project with JtR. Unfortunately, the program is having difficulty recognizing the hash types of the passwords after hashing them.

Currently, based on the information found here:
John the ripper does not crack password
 my process is to encrypt a password via openssl using AES-256, then piping the result into sha256sum on the command line

echo -n "password" | openssl enc -aes-256-cbc -a | sha256sum | cut -f 1 -d " " > hash.txt

The result for this being

I have also attempted piping the encrypted password directly into openssl's passwd function, although this has been less successful than the previous command

echo -n "password" | openssl enc -aes-256-cbc -a | openssl passwd -1 -salt xx > hash.txt

In any case, john does not seem to be able to recognize the hash format.

What exactly is happening here? It should be simple enough for JtR to recognize the encrypted hash, but obviously something is being mangled in the process. Is there an additional newline or other improper character being piped in along with the encrypted password? If someone could enlighten me it would be greatly appreciated.

You're telling John to decrypt a raw SHA256 hash, but you're creating hashes of an AES-256 encrypted string, not of the password itself.  Because the AES-256 encrypted string is effectively a very random blob, John is unlikely to ever guess it.

Try, instead, simply hashing the password and then running John against it:

root@kali:~# echo -n password | sha256sum | awk '{print $1}' > hashes.txt
root@kali:~# john --format=raw-SHA256 hashes.txt
Using default input encoding: UTF-8
Loaded 1 password hash (Raw-SHA256 [SHA256 256/256 AVX2 8x])
Warning: poor OpenMP scalability for this hash type, consider --fork=4
Will run 4 OpenMP threads
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:/usr/share/john/password.lst, rules:Wordlist
password         (?)
1g 0:00:00:00 DONE 2/3 (2020-04-19 14:17) 10.00g/s 655360p/s 655360c/s 655360C/s 123456..gbby
Use the "--show --format=Raw-SHA256" options to display all of the cracked passwords reliably
Session completed
root@kali:~# john --show --format=raw-SHA256 hashes.txt
?:password

1 password hash cracked, 0 left
root@kali:~#


How does faked DNS manage to downgrade preloaded HSTS? Yesterday, in a bid to entertain myself for a while, I was playing around with DNS servers. I set up a DNS server locally, which I then set as my primary DNS server. Within it, I added some records that overrode what would otherwise be existing domains: I pointed Google, Facebook, Twitter, etc, at 127.0.0.1 (google.com. 60 IN A 127.0.0.1), where I had a web server running.

To my surprise, it worked. Visiting http://google.com returned the web page as served by my local web server.

Thing is... google.com is supposed to have preloaded HSTS on it. I was under the impression that my browser should know that google.com is meant to only ever be sent requests via HTTPS, and hence hitting the HTTP version and getting a local page should not work.

Where are my assumptions wrong?

The domains google.com and www.google.com are not HSTS-preloaded. You can check that here. They don't even initially send a HSTS header.

Other subdomains of Google are preloaded, e.g. accounts.google.com.

Your assumption is correct that for a preloaded domain, accessing the site over plain HTTP in your browser should not be possible, regardless where you point the DNS. You simply checked the wrong domain.


Should the whole web *really* be encrypted? Isn't plaintext sometimes faster/better? It seems to be commonly accepted nowadays that all internet communication should be encrypted.
(For example, this is evident in how the HTTP 2.0 standard outright requires HTTPS.)

However, I have a hard time believing that this is the right way to go, but I feel I'm alone in this position.

Consider, for example, the download of large files (movies, application installers, etc.).
If the files are unencrypted, the same exact copy can be sent to multiple clients, allowing for better caching and network performance. (Of course this applies equally well to small files, but the motivation for large files is more apparent.)
Furthermore, this does not imply a security vulnerability: a server can send the file's cryptographic hash over HTTPS, but host the file itself over HTTP. The client can then easily check the hash of the file to verify its integrity.

Why is this approach undesired? Why should the entire web be encrypted, even when the communication content is itself clearly public knowledge and easily protected via a hash?

The additional overhead caused by the encrypting your payload is almost zero since CPUs today can encrypt at speeds of up to hundreds of MB/s. The only noticable delay is during connection setup, as you need a few additional round trips to set up SSL/TLS. However, if you are transferring large files, this round trip cost is negligible.

Yes, caching of unencrypted files will increase performance. However, there is a lack of privacy. The operator of the caching server can see the contents of your download since it is unencrypted. Therefore, the approach described above is not as common.

However, if you only need to verify integrity and have no need to maintain privacy, then the method above is fine.


Why is there no easy heuristic protection against ransomware? After the recent spread of the WannaCry ransomware - which proved one more time that this kind of attack is capable of causing serius damage and dangerous disruptions to critical services - I asked myself why there is no easy protection against this kind of malware using a heuristic approach.

My reasoning is the following: While the attack vectors of ransomware may be of various kind, ranging from careless user action to zero day exploints, the action is always roughly the same: Lots and lots of files are opened, encrypted and then the encrypted file is stored in place of the orignal one.

I don't have deeper knowledge on the working principles of antivirus protection, but I am led to believe that this kind of action should be detectable relatively easy with a heuristic approach. One could for example watch for processes that perform mass reading and writing operations, with the output files typically having much higher entropy than the input files. Also, one could watch the currently running processes for sending instructions to the CPU, which appear to contain encryption steps. Although the latter is probably harder to achieve, I think it should be feasable given the rather small number of widely-spread encryption algorithms.

Without doubt, this would not provide perfect protection against ransomware. When the ransomware has started encrypting, it will take some time until the antivirus kicks in and there may already be some lost files. But of course, it will be better to lose some files instead of losing them all. Also there will be quite a number of false positives, which can be annoying for the user. Then again, some antivirus suites ask for any connected keyboard, whether it is really a keyboard and not some manipulated USB device, which I would consider as similarily annoying.

When searching online, the only similar approach I was able to find, is the software CryptoMonitor, which apparently has been aqcuired by Malware Bytes. But judging from the little info I was able to collect about it, however, it seems not to have hit the mass market. Also, I am not aware of any similar approaches from the known antivirus software vendors, or at least I could not find it.

This leads me to the conclusion that my idea for protection against ransomware is just not working. But why wouldn't a heuristic approach work in this case?

There is. Programs like Cybereason Ransomfree claim to do exactly that. From their FAQ:

  Cybereason RansomFree watches the way applications interact with files, and when it detects ransomware behavior, it stops it immediately before the files are encrypted. Cybereason RansomFree uses pure behavioral detection techniques and does not rely on malware signatures.
  Cybereason RansomFree deploys bait files strategically placed where ransomware often begins its encryption. The solution watches the way applications interact with files, and when it detects ransomware behavior, it stops it immediately before the files are encrypted.
  Cybereason RansomFree uses pure behavioral detection techniques and does not rely on malware signatures.

I have installed it on my machine. It creates hidden directories with files that it monitors on the desktop and on every partition.

I have not tested its effectiveness yet (e.g. by quickly modifying all the files in one of those directories).

Note that this kind of protection may not be a guarantee against all effects of the ransomware, because you have no control over the order in which ransomware processes files (some files will already be encrypted before the attack is detected). Also, if the prevention is based on the rate of the file modifications, the malware may slip through when it throttles its own execution (some variants are known to do that).


Good Security tool for PHP- Suhosin vs Spike vs PHPIDS Do I have to check/test my code beforehand, or do these tools inform me when an attempt is being made in real time? Secondly, which one should I go for -- Suhosin or Spike or PHPIDS or a combo?  What are the differences between them?

Spike is a static analysis tool and you should run it on your code before deploying it on your server. It will attempt to highlight any potential programming error which you will then need to take action to fix.

Suhosin and PHPIDS will alert when an attack / event is detected in real time.

Suhosin in my experience is more about run time protection as opposed to alerting potential attacks. However it will alert on events such as scripts trying to raise memory limits and other such actions.

I have never personally deployed PHPIDS, but looking at the features that it provides you may also want to consider Apache mod_security. With mod_security it will detect events such as SQL Injection and depending on the configuration it can be logged, blocked, logged & blocked, or some other action can be taken.


Network security question (NLB and 2-way TLS) I have a situation that can be better illustrated in the network diagram below.

My scenario:

Client Web Server (external party) is using TLS 1.2.
In my network, My Web Server is fronted by a NLB (Network Load Balancer).
The NLB is using TLS 1.2, supporting 2-way certificate authentication between Client Web Server and NLB over HTTPS connection.
My Web Server (old server) is using TLS 1.0.

Questions:

1) Is it the best practice / recommendation to terminate (i.e. offload the TLS 1.2 certificate) at the NLB side?

2) If I want to maintain HTTPS connection between the NLB to My Web Server, what options do I have? Note that My Web Server (old server) is using TLS 1.0. Are there any limitations to options?

Any recommendation will be appreciated.

Thanks,
Medan

If "Sample Network" is a trusted network, and access is limited to machines (and possibly people) that are fully trusted (such as in a DMZ), then it would be better to terminate TLS at  the load balancer, and have plain HTTP between the LB and the web server.

Is there any requirement to have HTTPS between the load balancer and the web server - what advantage does it give?


Securing my network: unmasking spoofed mac possible? In Kali you can:

airmon-ng start wlan0
ifconfig mon0 down
macchanger -r mon0       (-r changes mac id to a random number)
ifconfig mon0 up

This attack for example: aireplay-ng -0 2 -a [ap mac #] -c [client mac #] mon0

While using snort it detects the attack but with the spoofed mac.

In wireshark focused on mon0 you can see the source and see its a --deauth packet to client mac but how can it detect a spoofed mac and see the real one?

In some cases, you may be able to detect if a MAC address has been spoofed (see below), but it is not possible to detect the original value only by analyzing traffic captures. That is because the network card simply sends another value than the one which it is programmed to send. The original value will never be found in the packet content, if another value is in use.

By analyzing a MAC address, you can check if the OUI corresponds to the ones used in your organization or if it doesn't correspond to any known OUI (e.g. 12:34:56:67:89:10). Of course, it is trivial to set a valid MAC address, thus making detection impossible.
aa

Image source: Wikipedia


Security of Site-to-Site VPN vs Client VPN My company provides a service to another firm and connects via VPN several times a day. The service involves accessing an intranet web-based application and copying files from one server to another when necessary.

Currently, two users connect from their PC to the firm's Cisco firewall using the Cisco VPN client whenever they need to. The PCs are turned off out of office hours. The VPN password is stored on the PC with a dedicated tool encrypting with SHA-256.

Now, the firm says we must switch to a site-to-site VPN as they deem it simpler to control. We are concerned mainly because we fear that we become an integral part of their network and become partly responsible for its safety. We think that it's easier that a hacker gets into our firewall on saturday night and penetrates the firm's network, than that a hacker gets into our network during the day and gets to the right PC at the right time when the VPN is in use.

Assuming we have a decent firewall without known vulnerabilities (and both companies aren't high profile targets), are we overly concerned with this switch? Are there any other downsides of using site-to-site versus client-based?

Hmmm.

Thst you say "using the Cisco client" makes me think you are already using a VPN.

It seems odd when you are the service provider that your customer should dictate how you provide that service. Particularly if this is a purely technical service (e.g. a web based application). I can understand that if its more of a business service - such as managing multiple devices within the customers network, that a VPN would be the right solution - but for some sort of application service then a VPN is the wrong approach - by default it gives too much access which you then must tailor down to the minimum necessary to perform the function. OTOH using an TLS wrapped service, with client certificate validation, protects both you and your client.

Given that you appear to be in the situation where your customer thinks that a site to site is the only viable solution, it is of course quite possible to setup a "network" at your end which (from your perspective) appears to be part of the customer's network and simply implement a better connectivity solution from there into your actual network. But this is mostly conjecture - I know nothing about what this service is, nor your customer's motivations - you really need to speak to them and understand the problem properly (or provide more information here).


Are Printers running Linux 2.6 something to be concerned about? Our office has a number of printers which, according to nmap are running Linux 2.6.X with a whole bunch of open ports 80

The answer depends on how the printers are being used and who they are exposing themselves to. Assuming they are only listening on your local network, then the old kernel (and presumably other old software it runs) will be vulnerable to a variety of attacks. An attacker on your local network may be able to compromise the printer. If the printer is being exposed to the global internet, then there are bigger problems, and it may be possible for people all around the world to gain access to the printer and LAN.

While updating your printer's software is not likely to be possible, you can use a firewall external to the printer to block the open ports and only allow trusted connections from trusted sources.


How can I design a password reset function, which does not reduce security for users who can remember their password? We have a web app for which some users want to have a password reset function.

I don't want to enforce a particular level of security for the users. So if a user picks a strong password which she is able to remember and then proceeds to store sensitive data in our system, then we want to keep that data secure.

At the same time there is a constant stream of users who forget their password and who do not want to bother with security at all, in fact they don't even want to be asked questions about security.

How can I create a password reset function for the second group of users without reducing the security for the first group of users?

Have a user-configurable boolean value for "reset allowed".

If you have their e-mail / some out-of-band means of communicating with the end user

When the user clicks the "I forgot my password" link, if "reset allowed" is true, send a password reset link to the e-mail account associated with the user account. Make sure you use an e-mail service that first attempts end-to-end encryption (so that, if their mail server supports that, the link never gets sent in plain. And if their server doesn't support that, they aren't denied the link).

Rate limit the number of times that e-mail can be sent to the same account (e.g. 2 resets per day) so someone can't use that to spam the account. Don't let the user know if an e-mail has been sent or if the account they mentioned even exists.

If they don't click the password reset link, nothing should change. If they click it after a certain timeout period, or if between the e-mail being sent and the time of it being clicked "reset allowed" has been set to false, nothing should happen.

If you don't have an out-of-band means of communication

If "reset allowed" is set, use a challenge-response mechanism such as user-configurable security questions. If they answer the questions correctly, allow them to enter a new password. You might also want to consider hashing the responses.

You could, of course, also use something like TOTP, but chances are if they don't have the password, they also won't have the key needed for this.

Either way

Conduct the entire exchange over an encrypted channel. Unless you're trying to stop the NSA from stealing credentials, SSL should be enough.


Using Encrypt-then-MAC in SSL SSL typically makes use of MAC-then-Encrypt technique instead of Encrypt-then-MAC (which is usually considered ideal for most of the scenarios). I myself don't have a full insight knowledge about the merits and demerits of both the techniques, but based on what I'v read and understood so far, I think using Encrypt-then-MAC in case of SSL would have made more sense.

I also think that this would have protected SSL against many attacks in the past. For example, while talking about preventing Padding Oracle attacks on SLL, @Tomas Pornin quoted in one of his answers:

  One must note that if SSL had used encrypt-then-MAC, such problems
  would have been avoided (the faulty records would have been rejected
  at the MAC level, before even considering decryption).

And, even after all these attacks in the past, SSL is still NOT using Encrypt-then-MAC! So, my question is, why do we still use MAC-then-Encrypt in SSL? Why not simply use Encrypt-then-MAC for fixing the problems, instead of applying small patching band-aids everytime? What is it that is stopping us from using it in case of SSL?

The various "patches" which have been applied on SSL/TLS have the nice characteristic of not changing the on-the-wire protocol: they are implementation tricks which work around the issues implied by MAC-then-encrypt. One way to say it is that it is possible to implement and use MAC-then-encrypt securely, but it is not easy.

This backward compatibility with the existing protocol allowed the patches to be implemented and distributed and used right away, whereas a new protocol would have taken years to be widely adopted. For instance, problems with CBC mode in TLS 1.0 (what the "BEAST attack" leverages) have been fixed by a new protocol version (TLS 1.1) since 2006, but browsers have begun to support it only about 2 years ago, and a large proportion of Web servers still don't support it. A new protocol which fixes issues does not do any good if you cannot use it, because it is not supported on the other side of the connection...

Apart from waiting for a yet-to-be-defined TLS 1.3, which could take some time to be specified, let alone implemented and supported, you might have some luck with TLS 1.2, which supports GCM. GCM is an encryption mode which combines symmetric encryption and a MAC, and does it properly (i.e. MAC-then-encrypt, roughly speaking). Of course, not a lot of browsers and server support it yet, but at least the specification/approval part is done for these cipher suites.


What should I ask a prospective security consultant? What should I ask a security consultant to see if they are legitimate or not?

I'm looking to hire someone to perform an assessment, but I'd like to make sure that someone is reputable first.

Invent a scenario similar to the one you want them to work on, and get them to walk you through how they would tackle it. You'd want to assess their ability to understand the needs of your business as well as their technical understanding. The key factor would be whether they ask the right questions and give you the right answers.

For example, you might want someone to assess your e-commerce infrastructure, so your scenario might start with the question:

"We want to put a new website up - how should we secure it?"

A good candidate would immediately start asking about the data involved, and the level of risk you're willing to tolerate. A bad candidate would get immediately proscriptive.

If they answer that to your satisfaction, or draw the information out of you, you can expand it to:

The website will contain a shopping cart. How should we secure that?

... etc. Ideally, in this scenario, you'd have a candidate who looks at wider issues than just IT - policies, procedures, staff training, backups and backup security all play a part as well as firewalls and IPS.


Question of importance of FIPS in security implementations I am by far, no security expert but I experience on the subject working in Java (JCA,JCE and JSSE).
Anyway, recently there was a discussion about FIPS compliance.
I looked into this and SUN's libraries are not FIPS compliant per se.
Additionally, Bouncy Castle, which I use extensivelly, and as far as I know is considered as the best security library is not FIPS compliant either.
So my question is, how important is it, to provide an implementation that is strictly FIPS compliant?
As a simple example, in building a secure site should one explicitely state whether it is FIPS compliant or not?
Any input on this is very welcome.

Thank you.

The most common reason that you need to be FIPS compliant is your company is required to by law or for other compliance reasons. FIPS compliant just means that your encryption has been validated by an authoritative body and there are no inherent flaws. There are also no discovered flaws in a lot of other encryption libraries like bouncycastle.

The reasoning behind FIPS vs no FIPS is no FIPS relies on the fact that no one has found a problem but doesn't really say if someone has looked before. FIPS is proven based on active testing and security standards.

In the end, it doesn't improve your overall security posture but it will make management feel better if it's FIPS.


Why am I getting strange HTTP requests for non-existing pages? I am running a web server and watching what people request.  I have been getting frequent traffic like:

GET /phph/php/ph.php HTTP/1.1

or

GET /mrmr/mrm/mr.php HTTP/1.1

Are these scans?  Are the clients checking if my server is already compromised or are they checking if I am vulnerable?

As far as I can tell, since I don't host such directories, such traffic is a scan for compromised machines; I do not know for sure because I think it unsafe to click the links Google provides when I search such things.

These types of spurious requests are very, very common. They are either looking to see if you are already compromised, or looking to get your server to throw an error to gather info about your server (from error messages).

You aren't the only one:

http://shadow.wolvesincalifornia.org/awstats/data/awstats092014.shadow.wolvesincalifornia.org.txt

# URL with 404 errors - Hits - Last URL referer
BEGIN_SIDER_404 193
/admin.php 1 -
/root/back.css 1 -
/drdr/drd/dr.php 2 -
/hkhk/hkh/hk.php 1 -
/wp/2011/07/19/&amp 6 -
/ahah/aha/ah.php 1 -
/andro/back.css 1 -
/wp/comments/feed/ 1 -
/wjwj/wjw/wj.php 1 -

We all get spammed by these requests.


TPM: signing key or Attestation Identity Key? I am dealing with the TPM right now and do not get why there is a need for an extra signing key. Instead one could use one of the Attestation Identity Keys (AIKs) for signing as well?! Using different keys shall be good practice but I would like to get a more detailed view on that issue.

I figured out that one advantage is that the signing key can be migratable. So changing the plattform/tpm would not necessarily end in revoking the created certificates.

Are there further reasons for a separate signing key?

AIKs are only allowed to perform two signature-based operations:

TPM_Quote, which generates a signed statement of the state of the PCRs using an AIK; this is the operation used in remote attestation.
TPM_CertifyKey, which generates a signed statement that another key (not the AIK) is in the TPM's storage hierarchy and is non-migratable. (Obviously, the key being so certified must have these properties.)

In particular, AIKs cannot be used in TPM_Sign, meaning it is impossible to sign arbitrary data. Otherwise, it would be possible to generate a fake quote, and remote attestation would be broken.

(Conversely, TPM_Quote must use an AIK; it cannot use a signing key.)

TL;DR: if you need a key to sign arbitrary data, use a signing key. If you're doing remote attestation, use an AIK.


How to prevent pay per show/click abuse? We have a webapp. 3rd party websites put our banners on their pages (banner is a snippet of HTML). They are paid for it using  "Pay per click" or "Pay per show" methods.
So 3rd party website's owners are interested in abusing this payment methods by e.g. clicking banner a lot of times/creating bots/etc.. I'd want to defend against such abuses.

How can I defend against such show/click fraud?

After reading some parts of AdWords help and this report I know that I should log some info about each click like exact time, IP address, user-agent, tracking cookie. And then apply some filters to those logs:

Period between repetitive clicks. If it's too low, discard all but one of them
Statistical analysis of clicks per time period. If number of clicks per current period is significantly larger than average, this activity should be reviewed
Check banner environment for reality: cookie support, JS code execution, comparison of user-agent and browser JS detection, comparison of JS detected locale, timezone and source IP
If percent of already detected invalid clicks originating from a particular IP address is significantly higher than from other IPs, and number of clicks is significantly large, then all clicks from this IP address should be discarded
Shows/clicks coming from IPs in http:BL of Project Honeypot, countries not in areas where users live, datacenter IPs

Please, advice other filters that will be useful. Also I don't know proper settings that should be used in those filters. What are they?

As with all fraud-detection mechanisms, this problem is inherently unsolvable in the absolute sense, as whenever you come up with a solution, the attackers will simply modify their attack to account for it. This is also why you simply cannot find a "ready-made" solution for this type of problem on a site like this. Once a solution is posted, it becomes the template for the fraudsters in determining how to avoid detection.

But that doesn't mean there's nothing you can do.

This is a classic data-mining problem. With a large enough sample set, you watch for patterns and statistical anomalies the attributes associated with the data. It could be the user agent, netblock, referrer, timing attributes, or just about anything that the attacker didn't think to compensate for. When you see an increase in traffic that all share some unusual attribute, there's a higher statistical likelihood that you're seeing non-normal (potentially fraudulent) traffic. The math behind what you'll need to implement will almost certainly be based on Bayesian analysis which will help you flag the outliers.

The larger your dataset the better you can eliminate errors, and therefore the more accurate your model will become. This is one of the primary reasons why very large ad networks can do a much better job at this than smaller ones; the sheer data volume can be a huge advantage in itself.


Are Keystroke and Click Loggers Legal? I worked with the firewall "Nobero" which is paid and bit expensive.

It is a complete Network Firewall including groups policy, banning URLs and social sites.

But It has a feature of tracking users' keystrokes and mouse clicks (which is captured by the desktop client of the same firewall)

It captures all the keys including everything if he/she uses facebook, gmail, or other personal sites. It captures everything and an administrator can see them.

My question is whether it is legal to capture keystrokes and mouse clicks without notifying the user

"Legal" means that it depends on the jurisdiction, so you will get at least one answer per country, and in some cases (e.g. federal states like the USA) many distinct answers for a single country.

Usually, in a business context, employees have a right, and an expectation, of privacy, meaning that spying upon their activities is not legal; employers cannot read emails, listen to phone calls, or, indeed, log keystrokes without knowledge and consent of the employees. However, in many jurisdictions, corporations can edict security policies that users must explicitly agree to when they sign their employment contract, and these policies may allow the employer to do some spying. This does not, however, entitle the system administrator to use the data which was thus grabbed.

Of course, even if made "legal" through user explicit consent, generic spying and grabbing of passwords and keys is a very efficient way to make employees very unhappy.


Why does SSL Labs now consider CBC suites weak? Why does SSL labs now mark CBC 256 suites as weak, although equivalent GCM and ChaCha20 are considered strong? Until a few months ago, it was unmarked in reports (neither explicitly as weak or strong), and it is still unmarked in their client lists.

The suites in question are:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA

The SHA1s are a requirement to support Android 5 and 6 with 4x100% score. It still gets 4x100% score, but it marks it as weak, which from an OCD perspective doesn’t look “professional”.

While CBC is fine in theory, there is always the risk that an improper implementation will subject the connection to padding oracle attacks. Time and time again, CBC implementations in TLS have shown themselves to be vulnerable, and each time an implementation is fixed, it seems yet another bug making padding oracle attacks feasible appears. Lucky Thirteen was published in 2013, and variants of this attack based on side channels keep popping up. SSL Labs is just observing history and learning from it.


TrueCrypt on shared cloud folder (Dropbox, Skydrive,...) So here's the situation: I have a Skydrive folder that is shared with all of my colleagues at work. For added security we would like to encrypt our Skydrives with TrueCrypt. But what will happen when I upload or change a file in Skydrive? Will my colleagues, that use a different password, be able to view and edit this file? Or will TrueCrypt mess up everything with everyone else?

You would need to share the password as truecrypt is just a filecontainer on top of your existing filesystem. I'd strongly advice against using Truecrypt as my experience with dropbox has shown that every time you change something in the container, the complete container will need to be reuploaded.

Furthermore for the sake of confidentiality I would really refrain using personal Dropbox and Skydrive accounts for any work related matters.

Correction:
Dropbox uses delta sync (so it will upload only the changes of the big file) and a change in a small file inside a truecrypt container will not result in a complete new container. https://superuser.com/a/308224/165352

Hence, a truecrypt container shared online with some service that supports delta-syncs will be fine when it comes to file uploads etc. However, you could still have the usual problem of simultaneous edit of the same file.


AWS VPC - should connections between instances be over SSL? Say I have a few EC2 instances in an AWS VPC network, each assigned its own private address for the subnet at creation. Say one of them is a DB, and another one some kind of web app talking to the DB.  The DB makes sure to authorize only a certain segment of IPs on that subnet.

How critical is it that the communication within this subnetwork is encrypted with SSL? If eavesdropping occurs then you should be able to see the password get transmitted over cleartext.

Assuming, for the sake of argument, that there aren't exploits in AWS, how possible is it to either eavesdrop on the communication to the database instance, or to even MITM it?

When you run your own physical datacenter, you can be relatively confident that your data won't be snooped on internally, but how does cloud hosting alter this approach? I imagine the trust levels are a lot lower.

Amazon claims that AWS VPC is "logically isolated" from the other AWS instances, and from the Internet. "Logically" means that it is done in software, not with dedicated hardware system. An AWS VPC can be connected to your VPN and it will use IPsec for that external connection, but this does not mean that internally IPsec is used. In fact, how the "isolation" is really enforced is not documented, so that's a big unknown.

Assuming that Amazon is not hostile to you (in which case you would be doomed anyway), and that furthermore they do their job properly, then your communications between your systems should be safe from eavesdropping or interception by third parties. However, you can botch it if your servers reference each other by name and you let your internal DNS be poisoned externally. I suggest you use explicit /etc/hosts files so that your servers may not be convinced to use wrong IP addresses, letting the data escape into the Wild Internet.

Using SSL anyway would make things easier if you decide, in the future, to migrate your servers into some other cloud provider, or if you cease to be so trustful in Amazon's competence against network attacks. After all, IT security is known to be hard.


Does EAP-(T)TLS mitigate against KRACK? It is my understanding that EAP-TLS and EAP-TTLS do not trust in WPA2 4-Way handshake, essentially establishing an authenticated tunnel between client and server independant on the WPA2 protocol.

In this scenario, would KRACK reveal plaintext from the victim, or it would be unable to break the TLS tunnel and confidentiality would be ensured?

It is my understanding that EAP-TLS and EAP-TTLS do not trust in WPA2 4-Way handshake, essentially establishing an authenticated tunnel between client and server independant on the WPA2 protocol.

Your understanding is wrong. EAP-TLS and EAP-TTLS (as well as EAP-PEAP) are methods used to authenticate a supplicant (i.e. client) to a RADIUS server when using WPA/WPA2-Enterprise (i.e. 802.11i). All of them create a TLS tunnel between the supplicant and the RADIUS server through which the authentication is passed.

In an 802.1X transaction such as this, the client is not actually connected to the network until they are authenticated. The device the client connects to will proxy the 802.1X transaction from the supplicant to the RADIUS server. Only after a successful authentication is the client allowed to finish establishing the connection to the network.

In the case of 802.11, it is after the successful authentication that the client can complete the connection and establish encryption with the access point (often referred to as the WPA2 handshake).

  In this scenario, would KRACK reveal plaintext from the victim, or it would be unable to break the TLS tunnel and confidentiality would be ensured?

KRACK would be unable to break the TLS tunnel used by the EAP method as KRACK does not attack the TLS protocol. Rather KRACK attacks the WPA2 handshake which establishes the encryption keys to be used between the client and access point. It is the encryption between the client and the access point that is vulnerable.

The TLS tunnel used by EAP methods is established between the supplicant and the RADIUS server, not between the client and the access point. Once the authentication completes, the TLS tunnel is torn down.

Post successful authentication, when the process continues connecting to the network, is when the WPA2 handshake takes place and KRACK would come into play. This will then compromise the encryption between the client and the access point.


xmlhttprequest with https - can I test the fingerprint before sending any data I am making https calls in javascript via xmlhttprequest.
I know the server and its public key in advance. For extra security, I would like to check the public key (or its fingerprint) if its is what I expect.

But I want to do that before I send any data over the network and if the fingerprints do not match, I do not want to send any data. Is that possible with xmlhttprequest? I found this page, but  here the the fingerprint is only retrieved after a request has already been made.

I found this page, but here the the fingerprint is only retrieved after a request has already been made.

You need to do some kind of request to get information about the peer, because somehow it needs to collect these information. But of course you can do a dummy request (pre-flight) not containing any sensitive data.

But note that a normal application has no access to the fingerprint or certificate. The example you refer to can only be used inside a Firefox extension or from an XULRunner application which is clearly stated:

  ...This code requires elevated privileges to run; you can only call it from a browser extension or from a XULRunner application.

Outside of these elevated privileges, that is inside a normal web application, you can only trust that the browser does the right thing but you can use HPKP to make sure that the correct fingerprint of the certificate will be used, at least with browsers supporting HPKP.


How can I identify that my page is requested by robot, but not user's browser? How can I detect that my page is requested by robot, but not user's browser?
I'm aware of basics tricks:

Watch for incorrect headers or urls. For example, urls with hash or header with full url - GET www.yoursite.com/test
Detect that several unrelated pages were requested directly by some IP (not good enough)
Watch for missing headers
Watch for obsolete User Agents

Is there any other ways to detect robots?

UPDATE: some good robots identify themselves in User-Agent header:

User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Javascript detection seems to be the common way to detect a bot, by having a random token generated using Javascript and being sent along with requests.

I like the idea of having a 'honeypot' page on your web application. This page would be linked to using a hidden link, which no end user would ever see. This way if this honeypot page is ever reached (by a bot scanning the HTML source for links), you can be pretty confident that this is a bot or other malicious scanner and temporarily block that IP address.

There are also tools out there (such as weblabyrinth) which aim to trap bots in a loop by dynamically generating bogus links for the bot to follow.


What's the safest way to access my US-based bank's website from within Mexico? VPN vs SSH vs HTTPS? I will soon be moving to Mexico and living there for an extended period. During that time I will need to occasionally access my US-based bank's website. I'll always be connecting using my own laptop, which is guarded and clean from infection. I have no specific reason to worry about my net traffic in Mexico being intercepted but I still want to take every precaution I can.

My options for accessing my bank's website are:

VPN - Use a US-based VPN service to tunnel from Mexico net space to US net space. I'm not concerned about the VPN logging my traffic, I only need to be sure that they implement the protocol correctly. I'm looking at StrongVPN and PrivateTunnel, I'm open to suggestions for others. Once I get into US net space I feel like I'll be reasonably safe from interception, I'm counting on HTTPS to cover me from the VPN exit to the bank's servers.

SSH - Connect to a trusted computer here in the states and then browse from that. This might be the safest but I don't think I'll be able to have anytime-access to a computer here. Plus, if the computer or router goes down I'll have to rely on someone else to fix it, also a shaky possibility. Could I SSH into a VPS, or maybe use Tunnelr.com?

HTTPS - Rely on HTTPS only. I really don't want to do this. I think I understand how certificates work and about checking the certification chain and the warnings that browsers give when the cert appears to have changed. But I'd hate for HTTPS to be my only defense against interception.

Is there another option for connecting securely? What do you recommend?

Edit:  I think I've answered my own question.  I'm thinking I'll get a VPN, probably Tunnelr.com, that way all my traffic is protected.  I know nothing about the networks I'll be connecting to when I'm in Mexico and I think a VPN is the best and simplest solution for my current needs.

Still, any feedback or comments are welcome.  Thank you!

The only reason I would recommend tunneling HTTPS over VPN or SSH is if you (1) don't trust your banks implementation of SSL/TLS (weak cipher suites) and the network(s) your traffic is traversing or (2) you want to hide the destination(s) your browsing to up until the VPN/SSH exit point.

Provided HTTPS is implemented properly, it should be just as secure as VPN or SSH.

I would say compromise of your PC is more likely than compromise of data in transit due to a weakness in the bank's security.


Bypass login with SQL injection with additional password check I'm having some fun with SQL injection attacks, and I'm currently attempting to bypass a login using SQLi.

I think I've figured out the SQL query just fine, however this module also implemented an extra password check, to verify that the password input matches the query.

The webpage is served using Python and FLASK

query = "SELECT * FROM users WHERE username='admin' UNION SELECT null, password, null FROM users where username='admin' -- AND password='[User Input]some_password'"
result = db.execute(query).fetchallI()

# Then checks if the password input is equal to query output
row = result[0]
if row["password"] == password: # Problematic password check
  try:
    session["user_id"] = int(row["id"])
    session["username"] = row["username"]
    return redirect(url_for("bank.index"))

I'll probably be able to figure out the rest of the SQLi if I'm able to bypass the password check.

Any ideas?

If you are able to inject username I believe you will inject into SELECT * FROM users WHERE username='admin' that username part so we only need to return a password which we write to password input.

The payload for the username input:

nobodyhavethisusername' UNION
    SELECT 1 as id, 'myuser' as username, 'mypassword' as password --

And the payload for the password input:

mypassword

What did we do?

With nobodyhavethisusername we make sure this query will not return based on left of the union select.
Union select can only return 3 columns (I guess) and app uses id, username, password columns so we returned this columns with UNION SELECT.
We have a comment out at the end (--) without it SQL query will raise exception. Notice there is a space after the two dashes. MySQL has a "safety" feature built-in that treats the comment as a minus if there is no space afterwards.

The query then becomes like this:

SELECT * FROM users
WHERE username='nobodyhavethisusername'
    UNION SELECT 1 as id, 'myuser' as username, 'mypassword' as password --


Store password in Chrome exclusively online I have read about the functioning of Chrome for storing passwords. I realized that it stores an encrypted sql database locally and it also stores them online. I find it more secure to have them only online.
Is there a way to store them exclusively online ? Maybe by deleting the local database file ?

This would be a rather uncommon request. Historicaly, browsers programmers realized that user had to consistently type their passwords for web sites and decided to store them locally in an encrypted database. Then Chrome decided to allow an automatic synchronization of the encrypted database in the cloud, to allow an easy share between different devices. But AFAIK, you cannot bypass the local database even in Chrome.

But external password vaults exist like for example LastPass. It can be used as a Chrome add-on and stores your password vault in their servers. Of course a temporary local copy must exist locally, because the encryption/decryption is only local so that your master password never reaches LastPass servers. But AFAIK, the only permanent storage is remote.

That being said, local storage is often prefered for password vaults, the online storage being seen as a help for sharing the vault or to have a backup. So IMHO, you should think twice about what are the threats you want to mitigate with a on line only password vault.


The difference of Security Policy and Acceptable Use Policy ? Acceptable Use Policy (AUP) is a set of constraints and practices that users must agree and sign off to access the corporate network, endpoints, applications, and the Internet.

Information Security Policy is a statement of how the organization plans to protect the company's physical and information technology (IT) assets.

So is AUP part of the infosec policy?

The two concepts are related, but distinct. A security policy is generally somewhat detailed, and goes into depth beyond what every end-user must worry about. However, not all aspects of the AUP are security concepts; for instance, my school's AUP has a line forbidding the use of the network to suggest the school's endorsement of a political candidate, except when approved by the general counsel's office. AUPs are legalistic policies intended to govern conduct on the system; this goes well beyond protecting the IT system and into protecting the organization itself.

Now, in some places the information security office is also in charge of policy and regulatory compliance, as the ideas are often intertwined. But AUPs are not inherently part of the security policy, because they aren't primarily designed to protect the integrity of IT systems; they're to enforce acceptable conduct even if it poses no security risk to the organization, and involves no risk to confidentiality, integrity, or availability.


Best practice to share google drive API credentials for being used by a script? In a nutshell: Shall I share oauth2-credentials in our source code with the scope of full write-access to a google drive from a dedicated single-purpose google-account?

so, I've written a python script which saves some data into either a pre-existing google-sheets file or creates a new google-sheets file into a given google drive folder (both of which are publicly editable for sharing purpose between teams).

For this I followed the steps and tutorials outlined by google and other sources whereafter I have obtained oauth2-credentials needed for my script to be authenticated with the google drive and google sheets API.

Those credentials are derived from a single-purpose google-account which I have created for this script.

Now I would like to share this script with other team-members but am unsure about how to proceed regarding the credentials; either:

A.)
I would incorporate the suggested google workflow which would let the user of the script authenticate him/herself, i.e. the user starts the script, then is directed to the google-authentication weblogin, authenticates the script, and then the script would save and use those credentials of the user for writing data into a public google-sheets file (not necessarily a private one owned by the user).

This has the downsides that:

the user would trust my script with credentials which could enable it to read/write all of the data of the user's drive account. While I do not mean any harm of course, it still seems rather too much to ask and be responsible for
it breaks the intended straight-forward workflow of my script.
is not necessary at all technically, because the script shall only write into public sheets-files / drive folders; so why should it need write-access to all the user's drive files?.

B.)
hardcode the credentials of our single-purpose account into the script; which has the only downside that when the script's source code would be shared, that anyone could obtain those credentials. But these credentials would only enable an attacker to write/read data into the account's google drive, but not take control over the whole account itself due to the limitations of the scope of the oauth2 credentials (I've used the "https://www.googleapis.com/auth/drive" scope). Additionally, as said before, we would only use the script to read/write data into public sheets-files which are owned by real google-accounts, so never would we use the drive of the single-purpose account and thus no attacker could destroy our data.

Thus, I am rather opting for option B, but I can't help the anxiety which comes from hardcoding publicly readable credentials...

What would you suggest?

We decided for option A: users need to create client_secret.json and credentials.json files themselves. It is unfortunately not the most straight forward, but the most secure one. Sharing credentials in a public repo is just a big no-go, no matter the details.

Also for the sake of completeness: another alternative would be to have our application running on a server where we could save the client_secret, so then a user would just be presented with a browser-popup where he/she would authorize our service.

But we don't follow that option either since the script shall only contain the core logic and it shall be a base for other to develop upon.

That's our motivation behind the decision.