Creating my own tokens to secure communication with my API I have an API communicating with my client, now I want to secure that API so that onlyu my client can use it. I am planning to do the following, since I have no experience in this I have gathered all this from reading up on the subject and I need advice, here is my flow:

When a user signs in/registers, generate a token (ex: token = userId + date + radomvalue), save this token (hashed) in a DBtable together with userId.
Send token (hashed) to client, save in preferences for later use.
When calling API this token must be sent with the request, on server, we look through our token-table and see if we find the combination of userId+hashedToken, if we do, access is granted.

All communication is over SSL, here are my questions:

What should I do about the TTL on my tokens? And what If I end up getting 3 000 000 users, that means that every call I make to the API it has to look through a table with 3 000 000 rows, is that ok?
I obviously can't make my login/register endpoints require a token passed in the request to be accessed (since the client has not gotten it yet), is it okay to leave these "open"?
Is it okay to send plain-text salt+password to api since it is SSL-protected, then hash it on server-side?

EDIT: 4. Thinking more on this, wouldn't someone just be able to grab their access token from the preference-file and make calls to my API from their own app, as long as they have the endpoint, and edit whatever they want on their own user?

Threat model: I am building a game. I have a database where I save ranking, experience, as well as what version of my game you have (free, no-ads, premium). After someone makes a purchase I call endpointService.setVersion("userId", "PREMIUM");. This is the only real high value asset for me, since I don't want people to edit that themselves. I just want to protect my endpoints, but especially that one.

Is it possible to re-use an authorization mechanism, such as OAuth2?

Your client get a valid access token upon challenge (userID, secret) which is cryptographically signed.  Your server app can verify this token, and potentially take out any claims from it; so you don't need to look it up in a DB.  Even if you want to look something up, you'd need to look at in-memory key-value stores/caching mechanisms such as Redis.

The on-boarding (signing up / logging in) would be performed by an IdP, an identity provider.  See it as the system doing the actualy verification.  It will reply a unique token to the client; encoded and signed.  As long as your API makes sure that this is a valid token (signed by the right guy), then you should be good.

  Is it okay to send plain-text salt+password to api since it is
  SSL-protected, then hash it on server-side?

If you salt your password client side, then it just substitutes the password.  Unless someone does a MiTM (intercepting proxy, ...), and you don't log the request body, ... SSL would prevent you from eavesdroppers.  Whether you use the password, or the hash of the password; an attacker who captures it, would just send the hash as well.

  ...Wouldn't someone just be able to grab their
  access token from the preference-file and make calls to my API from
  their own app

Yes, everything that's on the client cannot be trusted.  You can try to obfuscate it a bit, but essentially, you can't be sure that it was your application sending it; and not another program (from someone who took the time and effort to reverse engineer it)


Should I obfuscate passwords before hashing?  Should I pre-hash them on the client?  What about salts? For fun, and in my spare time I'm creating a simple CMS for my own purposes (with hopes to release for wider use... later), using PHP. I'm currently working on the login scheme now, and have a few questions.

Note: The end result is always passed through crypt using blowfish and a cost parameter of 15
(Generally hoping that a cost param of 15 is long enough to hurt hacking attempts, but not long enough to frustrate users.)

Question 1: Assuming I'm using SSL/TLS: Do I really need to obfuscate the password any, before passing it to bcrypt (with the given parameters and a proper salt) and pushing it to the database?

Question 1.a: Since I don't have access to SSL/TLS (too costly from my webhost at the moment), is using the whirlpool hash (or something from the sha-2 family) client-side on the password before passing it to the server, a "good enough" case of security, or is that hash vulnerable to rainbow table attacks? (This assumes that I'm trying to put a tent flap on a tent, not on a bank vault. Bank vaults can afford SSL/TLS.)

Question 2: Is it worth it to create a new salt for the password every time the user logs in again, or do I just need to create a unique salt for that user of appropriate entropy when they register, and leave it?

Q1: "obfuscating" the password buys you nothing here, in terms of security; it just makes the code more complex, which is a bad idea.

Q1a: The hash of the password is "password-equivalent": presenting it is enough to get authenticated. So hashing changes nothing to security: this is equivalent to exchanging the password in cleartext. For security, you really want to use SSL -- you will not get much security without it. Actually you can forget all about crypt() and Blowfish and the "15" iteration count until you have enabled SSL: the lack of SSL is a much wider security issue. crypt() with Blowfish is very good, but using it without a SSL-protected password transfer is like putting a steel padlock on a tent flap.

Q2: The point of the salt is to be unique per password instance; a big enough random salt ensures such uniqueness "probabilistically". So you change the salt whenever you create and change a password (i.e. when you add a new user account, or when a user changes his password). There is no need to re-salt a password which does not change.


Simple solution to XSS I've got an idea as to how to defeat XSS so simple that it may work and was wondering if anybody had already done something similar.

The goal here is not efficiency but security.  In other words I don't care about trading bandwith for security.  My idea would be to serve every single character inside simple HTML tags.

Basically if the following, for whatever reason, would be a working XSS exploit: 0WNED!byXSS (which for whatever reason nobody would have detected), then it would be served as:

0WNED!byXSS

Basically a loop would make sure to only do:

write
write a single character
write

Could something like that technically work (performances and bandwith issues aside) and has something like this ever been done?

EDIT

Here's a (simplified) example of what I'm thinking about.

Instead of serving this:

    <title>Sample</title>

        Here goes user input
        potentially containing an XSS exploit

I'd serve this:

    <title>Sample</title>

        Here goes user input
        potentially containing an XSS exploit

The  tag was just arbitrarily chosen, any (preferrably one-letter) tag would do.

Various functionalities of the OS / browser seem to keep working correctly:

I can cut'n'paste correctly to the clipboard
I can still search for text (e.g. I can look out for "goes" and despite the fact that every single letter of "goes" is wrapped by tags the browser still finds it fine)

I take it that search engine would still correctly parse/index the content (not too sure about that that said).

To me it looks like quite a simple and effective way to prevent lots of exploits based on evil user inputs.

This seems like a silly solution to an already solved problem:

Use an HTML purifier library to only allow a safe subset, OR
HTML escape questionable input characters like <>'"& to their equivalents (e.g., < goes to &lt;).  Additionally, if you needed to allow some formatting (e.g., users can submit links, insert bold text) use a safe subset of a lightweight markup language so you convert user input like [google link](http://www.google.com) to google link.

If your scheme was perfect and inserted each character of the untrusted user input character by character between its own tag like hello, I personally don't see anyway for an attacker to easily do a XSS attack though someone else maybe able to think of something.

Lines of attacks that could work:

maybe they can mess up the DOM (by inserting stray < > symbols) and some random browser will try to fix and fix in some unsafe way.
maybe some browser will let an attacker insert backspace (unicode 08) and escape out of your tags somehow
or some browser internally optimizes consecutive tags -- e.g., converts it to hello.
or your method of parsing the user input character by character is flawed and surpassed.

Additionally, with your method I don't see how your scheme would allow you to do anything fancy that you may want to do; e.g., allow users to format text or post links or anything fancy.  In this case, its simpler to just ban the characters <>&'" that have special meaning in HTML.


Information on cryptolocker seeking ransom via email to certain email address A friend of mine was recently attacked by this new cryptolocker in an unusual way. I anticipate my question: what kind of cryptolocker is this, what could the attack vector be, and is a cure available to recover files? I know, and explained to the party, that the second is unlikely.

My friend ran a server with Win10 Enterprise. The day after office closed, Aug 13th, the malware attacked the system. It renamed target files (I have seen PDFs, XLSXs for now) into .exes by adding a long extension to get password email id [....] to brbrcodes@gmail.com where a long number stands instead of bracketed text.

The infection spreaded to MS OneDrive, where all files where encrypted and their originals deleted (we hope simply "trashed", so MS could have a backup).

The machine was unattended at the time of the infection. I don't have a sterile computer at the moment, and I won't dare open the exe files on any other machine until I get my hands on one. It's the best way to infect another machine.

I have doubts that this cryptolocker is capable of penetrating an unattended server (remote desktop was disabled, I have no record about it being firewalled correctly, let's suppose not) like WannaCry did. The infection did not spread into the LAN computers running Windows 10 when the office reopened and those computers were re-powered.

I don't yet have access to encrypted data. I just got a phone call and could see how the OneDrive files looked like, without opening any.

My research (link to VirusTotal not available here at the moment) found that the encrypted exe files may be plain SFX rar files, judging from the content type. So at least there are known rar password crackers, despite a brute force may be irrealistic.

Any info on this tool?

My friend ran a server with Win10 Enterprise.

This is the first mistake.

Anyway, the ransomware could be ACCDFISA v2.0 or a variant of it, see

https://www.bleepingcomputer.com/forums/t/618996/accdfisa-v20-ransomware-support-topic-filename-to-get-password-email-id-id-to-email-exerar/

With ransomware, Bleepingcomputer have a lot of information, q.v.:

https://www.bleepingcomputer.com/virus-removal/threat/ransomware/

It is usually wise not to boot the infected OS again, but (a) make a backup of all encrypted (and other) files to a separate backup destination, then (b) boot a Linux system from a USB or CD/DVD (Live System) then explore from there.  In fact, you may often do (a) from (b).

With (a) you may be able to recover the data later when more information (and possibly, a recovery tool) about it is available.  For (b) you need technical knowledge.

Easiest might be to replace all infected hard disk, then restore backups to them.  Look at the infected hard disk later while your server is already up.  Close all ports from the outside that are not needed (e.g. leave only TCP 80 and 443 open) using a firewall.

PS: The attack vector could be an open RDP port, this was observed in the past.


Authenticate users through Google using only an OAuth2 access token I have a question about having users logon to my service using their Google Credentials. I've gone through the Using OAuth 2.0 for Login documentation provided by Google.

The documentation mentions an id_token (JWT token) as the primary authentication token that can be passed around and verified by the application.

On the other hand, together with the id_token, the Google Oauth 2.0 API also returns an access token (that can be long-lived depending on the access_type)

Now, Facebook and Twitter also use OAuth to allow third party webapps with a "login using twitter" or "login using facebook" button. They assume that when an access token is retrieved through their APIs it considers the user authenticated.

Wouldn't the same be possible with Google? If I just use their OAuth 2.0 API to retrieve an access token and verify the access token by retrieving some user info like email, would that be considered a valid authentication flow ? Or am I missing something here ?

This post may answer your question. The best solution is to use OpenID Connect (id_token) since this will be the standard way to do it (still a draft).


What are the security implications of the POLi Internet Payments technique? POLi Payments is an Australian based online payment provider which has begun trading in New Zealand. They are supported as a payment option on some large eCommerce websites in New Zealand, including Air New Zealand, JetStar and The Warehouse.

It basically facilitates the verification that, as a customer, you have made a payment from your internet banking facility, so that the vendor may immediately complete the transaction.

It is highly attractive, because airlines do not charge a 'payment fee' when using POLi (which usually accounts for between $10 and $20). I am concerned with how it achieves this.

As an ANZ bank customer, after visiting the Air New Zealand website, I chose the 'POLi' payment option, and I was (while still on the Air New Zealand website), presented with my internet banking login page.
So, to be clear, the address bar contained "airnewzealand.co.nz", which had an iframe, whose address was pointing to "https://nz00400.apac.paywithpoli.com/IBCS/pgLogin".
I was then expected to log in to my internet banking, at which point I was presented with the pre-populated ANZ bank-transfer web page, with some fields disabled (reference code, amount etc).

What was being done is, the POLi server was requesting the bank website from the ANZ server, massaging the HTML, and passing the HTML to me. I then fill out the form, which is submitted back to the POLi server, who then passed that information back on to ANZ again.
This was repeated for every page.

Because of this, POLi was able to

pre populate the payment form so that I don't get the reference code or amount wrong
disable fields so that I cannot change them
validate the payment as completed so the transaction can continue.

What, if any, are the technical and social security implications of this technique?

Thanks everyone

You are entering your internet banking credentials into an interface owned by a merchant. The iframe comes from POLi, but there's no easy way for an end user to verify that, and the parent page would still have the opportunity to mess with the frame.

So you should not enter your credentials on this interface unless you trust:

POLi not to store or misuse the credentials you are giving them;
the merchant not to purloin the credentials, through clickjacking or just pointing the frame to some other source (phishing-style);
any third-party script providers used by the merchant (eg analytics, advertising) not to inject script content that would purloin the credentials;
the merchant to keep their entire web site safe from all XSS vulnerabilities that might let an attacker purloin the credentials.
POLi not to have any vulnerabilities where other parties can gain information through including their interface in an iframe and using clickjacking. (This is difficult to fully prevent when your interface must allow iframing.)

POLi are effectively doing a man-in-the-middle attack on your online banking and predictably some banks are upset about that. If you suffer from fraud (whether or not related to use of the POLi service), your bank might be able to argue that you have some liability, for not keeping up your end of the bargain to keep your banking credentials secret from everyone but the bank.

POLi aren't the only party taking this approach—see for example Germany's Sofortüberweisung. I personally consider it an insane idea, but it's hardly the first insane idea to catch on from the financial world.


Two SSIDs on same Access point- not good? If I were to offer two networks (one for trusted users and one to visitors) on one physical access point, is this dangerous because a visitor could compromise the trusted network across via the physical access point where both sets of wireless data propagate through?

Quite a lot of "enterprise" type access points offer functionality to allow multiple SSIDs on a single AP, and it's a pretty common configuration from what I've seen.

From a logical perspective the networks should be isolated (using VLANs or similar type of segregation).  You should also be able to specify different authentication mechanisms, encryption types etc.

If correctly configured and patched, this shouldn't pose a major risk, however it does increase the complexity of the environment which always poses security risk (ie, one logical misconfiguration can cause a serious issue)

In terms of the Denial of Service risk, wireless networks can effectively always be DoS'd if an attacker wants to as a powerful enough radio source can cause denial of service on the signal and things like Deauth floods are pretty hard to stop too, from what I've seen.


John the ripper is not identifying hashes I'm attempting to use JTR against a password protected zip. I have created the hash file using:zip2john filename.zip > filename.hash and i get a successful output:file.txt is using AES encryption, extrafield_length is 11

But when I attempt to run:
john filename.hashI get:
Using default input encoding: UTF-8
No password hashes loaded (see FAQ)

I have checked the FAQ and also checked a related post at "No password hashes loaded" John does not recognise my hashes but no luck

Does anyone have a solution?

There seems to be something wrong with your JTR installation. I suggest reinstalling/recompiling and trying again. When I run the hash you supplied in the comments, I get the following:

Loaded 1 password hash (zip [32/32])

It is currently cracking against a 160mb wordlist.


What are good ways to educate about IT security in a company? I work in a company where security is a "fire once forget forever" concern. The administrator sets up a solution and seldom follow up and maintain it. As a result, we've got a security policy that's kind of Swiss-cheesed: full of holes.

For example:

password security policies requiring changing every xx days with no backtracking, but accounts whose passwords are not changing handed to anyone to access special folders and database, even interns who then leave with the unchanging info
desktop and network antivirus, but no policy against USB drives. So far most viruses are caught and the culprit scolded, but one time with a 0-day is enough...

I have the feeling that security is a cosmetic concern here; the management want to be seen doing something, but is not doing the right thing, or not everything that should be done.

I thought about gray-hatting to demonstrate the problems in a dramatic way, but I don't think it's the right way to educate people about security in this context (perhaps in a completely security-focused company where everyone gets the situation).

So I'm wondering about a good way to spin the need for a more resilient security strategy. I'm not in a position to point out blogs and direct experts advice, because management doesn't talk English.

I was thinking about doing either an elevator pitch with some dramatic claims or a ten minutes demo of existing problems.

What do you think about these ideas? Are there recommended ways to point out security flaws when auditing for a client so as not to alienate them by basically saying "that's an half-bottomed work you did"? Are there particularly effective demos (just launching a firesheep? but that borders on gray-hatting) you'd recommend?

What has worked on several occasions for me is to stick the following chart in front of management:

Run down the list of threats (left column) and ask if they believe if any of those type people described may harm the business.

If so, then you may have won a battle.  Now you can describe what is needed to address each of those threats.

@atdre had a great comment about this chart on a different question:

  I don't like this because it doesn't convey the power of collusion or conspiracy. The underground community and underground economy puts all of these guys in the same room together and gives them tools to trade. – atdre`

So you may want to extend the list of threats to include communities.


HTTP status 302 and subsequent redirect I have sent a HTTP GET request to google.com and I get a 302 status. Now the location : url in http header is an http:// address, instead of https. When the browser visits this address I get back a 302 redirect again but with an https address in the location field of http header. The browser then visits this address and https connection is established. Also the IP of the first server which sent me a 302 redirect is different from the second 302 redirect sender. Finally the server with which I establish an https connection has a different ip.

My question is why do I not get a https redirect in the first 302 reply?

Also, I am using a program which sends an HTML GET request to a server and gets
back the response. How can I simulate this chain of 302 redirects to reach the
final server which returns an https page?

The program takes as input ./execfile_name host_name page.

Every time I supply the google.com hostname it connects to the same server (same IP). How can I get it to connect to the next server in the chain leading to the final one?

why do I not get a https redirect in the first 302 reply

Bad programming on the part of of whoever designed the system - bobbing out of https makes it trivial to carry out a MITM attack on the connection.

  How can I get it to connect to the next server in the chain leading to the final one

Use a better program. HTTP is deceptively complex. You can point a simple socket adapter at port 80 on a webserver, type in 'GET / HTTP/1.0\r\n\r\n' and get a sensible response nine times out of ten - but HTTP allows for more compex stuff like chunked encoding and redirects before you even start to consider session management and intrusion prevention.

Personally I use wget or curl from the command line (both of which can automatically follow redirects) or libcurl in scripts/programs.


Can Diffie-Hellman Anonymous be used as a cipher for SSL for one-way certifiate-based authentication I want to use Diffie-Hellman anonymous cipher for SSL. I also want to use a one-way certificate for server authentication. Is this possible?

By definition, when using the DH_anon cipher suites in SSL/TLS, there is no server certificate -- not certificate at all, indeed, since in that situation the server is not allowed to request a certificate from the client either.

If you want to authenticate the server, then the server you have in mind must have something special which distinguishes it from just any other machine in the Internet. Since everybody can buy the same kind of hardware, that "something special" must be something that the server knows. With a certificate, what the server knows is a private key in an asymmetric key pair (RSA, DSA...). Without a certificate, you can authenticate the server with regards to a shared secret (that both server and client know); see RFC 4279 (when the shared secret is a high entropy secret key) or RFC 5054 (when the shared secret is a password).


Why do some GDPR emails require me to opt-out and some to opt-in? I've noticed a trend in emails I've recieved as a result of GDPR, some of them are sort of 'opt-out' (or pseudo-opt-out where you just need to stop using their service) like so:

Our updated Privacy Policy explains your rights under this new law and will become effective on May 25, 2018. By continuing to use our site or app after this date, you are agreeing to these updated terms.

Or they require you to opt-in:

Hi, this is another one of those General Data Protection Regulation ("GDPR") emails where we request permission to email you, even if you are outside of the EU.
We hope that you'll opt in to continue to receive an email every now and then about our latest updates.

What differentiates the two requests? Are they storing different data on me, or is it more to do with their service? I've seen some companies that only email me about promotions etc (similar to the second quote above), and they have the pseudo-opt-out message, so I don't think it's service related.

It is not clear that the first kind of email is legal. A French association, la Quadrature du Net, is planning to launch a class action against five big tech companies (the famous "GAFAM") on May 28th about just this practice. Here is a summary of their arguments:

Article 6 §1 of GDPR lists six cases for processing personal data legally, one of these is user consent;
Article 4 §11 states that consent must be obtained in way that shows it is the will of the user in a clear, specific, informed and unequivocal way;
In the preamble of GDPR, it is explained that consent must be a positive action, and there can be no consent in case of silence, pre-checked boxes, or inaction;
Article 7 §4 states that when obtaining consent, it is necessary to consider whether processing personal data is absolutely necessary for providing a service.

As a consequence the "G29", the group of national data protection authorities in the EU, affirmed that if a user has no real choice, feels constrained, or will face negative consequences for refusing consent, then the consent given is not valid. The G29 therefore affirmed that GDPR guarantees that giving consent to processing personal data cannot be the counterpart of providing services.

Moreover if a company asks for consent as a legal basis for processing personal data, then they are forbidden from using the other legal bases of Article 6 for justifying their processing.

(The reasoning goes into deeper detail, if you can read French. What I have written above is just a summary.)

So the first email is essentially strong-arming you into accepting something illegal. If the class actions I mentioned above are successful, then you can expect smaller companies to follow suit and stop sending emails of the first kind (or face serious legal consequences).


Why Shellshock works in useragent string? I was wondering why Shellshock works when put in the useragent.

Based on what I could find it is because a web server (e.g Apache) uses the useragent string in its internal working.

Why would a webserver care about the useragent? AFAIK decisions based on useragent are made in the application with the programmer building the logic like if (mobile) : show mobile version etc.
Why would the webserver use an Environment Variable to handle this?! couldn't this be done through regular variable-value form with enough sanitization on  the input? As far as I know env-vars are not bash exclusive, they are defined in a system wide scope. I still don't get the connection!

A webserver could use the contents of the User-Agent header for logging purposes, to control access ("deny all bots") or return alternative responses ("mobile-friendly pages"). The validity of a header value depends on the application, it is not possible to write on rule that works with everything.

Consider the Cookie header. One site could purely use it to store a session identifier such as sessionid=01234567890abcdef. A different site might choose to store locales, such as lang=nl-NL. You could apply a character blacklist, but then someone might exploit a bug in your application which results in lang=--help being treated as an command-line option.

For CGI programs, web browsers will usually invoke the script and pass headers via environment variables such that the script can use this information as well. This is not limited to the User-Agent header, the values of Cookie might be more interesting for the script. The "form input" as you describe is different from the headers. Headers come before the message body.

Now about the Bash bug that leads to the "Shellshock" security issue, all you need is control over at least one environment variable. As you can see, direct CGI access on a webserver is one example where that condition is satisfied. You could also be affected when the program (PHP, Cgit, ...) invokes the shell, directly (via a shell script) or indirectly (via a shell command).


Do household IPv6 addresses introduce vulnerabilities? Apparently, for half a year already at least, my ISP has assigned me IPv6 addresses. I discovered this accidentally, while editing Wikipedia. So it seems my ISP started to support IPv6 addresses and decided it was a good time to give them out to users. (Unlike my college collegues, who are crazed with IPv6 shiny newness, I wasn't asking for this.)

Now pardon my incompetence.... But, AFAIK, unlike IPv4 addresses, IPv6 addresses do not use NAT and instead, are all directly routable from the Internet. Is this correct?

  If the computer is directly routable to the internet (a very bad idea in this day and age), common vulnerable ports will be scanned by bots and immediately exploited.

(source: this comment)

So it would seem that, contrary to IPv4 addresses, IPv6 addresses are inherently insecure; or rather, they are only as secure as the router's hardware. Is this correct?

Even though IPv6 addresses as such are globally routable, it does not necessarily mean that a system with one is exposed. In many cases (sadly not all), your consumer-grade router will employ stateful firewalling, meaning that new inbound connections will be denied by default. You can test this by performing a port scan of your device from an external IPv6-supporting host. If ports are open externally, you may need to add a firewall somewhere.

Second, there are way too many IPv6 addresses to perform mass scanning and exploitation as is possible with IPv4, so it is unlikely a host will be picked off at random. That said, if attackers can enumerate addresses through other means (e.g. you visit their website from an address), it could still be singled out and targeted.


What are the best IT auditing guidelines for Red Hat Linux 5.x+, including the critical data protection? Currently, I am a junior application consultant and we are maintaining huge amounts of redhat machines as servers. I am given the chance and liberty by my boss (unbelieveable!) to go do my own research regarding the security of our own systems. So I thought, maybe I should ask around here.... Hope you don't mind :)

So the question is: What should be audited in a Red Hat 5.x+ system to ensure the safety and make sure that proper measures will be taken to realize the given points here below:

Critical data protection
illegal access prevention
system integrity
uptime
system updates and patches are most recent
and etc...

What I want to achieve with this is to create a uniform and secure process to audit our systems and chart the status to intervene. In the end, I would like to look for possibilities to integrate this process with our monitoring systems.

look at this CIS benchmark  RHEL 5 Benchmark


What is meant by "Bulk Equipment Interference"? In a recent BBC article about the UK's Snoopers Charter it mentions the term Bulk Equiptment Interference. It states:

  But he expressed some reservations about a fourth practice - bulk
  equipment interference, which involves hacking into smart phones or
  computers over "a large geographical area", saying there was "a
  distinct (though not yet proven) operational case" for it.

So doing a bit of extra interneting doesn't really uncover much about this term, no wikipedia article or anything. The only extra information it uncovers is this article by gov.co.uk which is also very vague.

So in practice what is Bulk Equiptment Interference apart from just "Hacking things"

Do we know or are the articles purposely vague?

To expanded on what @mootmoot said in his comments, Bulk Equipment Interference is an euphemism (i.e Double Speak) for Monitoring internet connected devices over large geographical area.

You could relate this to USA's PRISM project. It essentially means that the UK will monitor your traffic in the interest of national security and it has the legal authority to do so.

While not specified, this most likely revolves around cooperation with telco and mobile providers. These organizations would be the hub that collects data, and passes it on to the GC for data analytics.

Privacy be damned in these modern times.


Using Keytool to export and change password of certificate in a KeyStore I'd like to use Keytool to export a certificate from my KeyStore.

I'd also like to change the certificate password, is it possible?

What I thought should be done is one of the following:
1. Changing the certificate password during export
2. Changing the certificate password after export

I couldn't find a way to do either option with keytool.

1- Changing the keystore password:

keytool -storepasswd -new new_storepass -keystore keystore.jks

2- Exporting the certificate:

keytool -export -alias mydomain -file mydomain.crt -keystore keystore.jks

keytool


Would PGP/GPG have been a better choice than SSL for browsers and http servers to encrypt traffic? I was curious recently when I heard that SSL had supposedly been broken by a certain rogue government agency, why SSL was chosen in the first place. Could it be that PGP would have been a more secure method to encrypt traffic? Today we also have GPG which is free and open. I believe PGP now offers an authentication hierarchy so it should have what's needed.

The talk is not of SSL being broken, but of the "rogue government agencies" weakening the underlying crypto mechanisms to make the task of brute-forcing the keys factors of magnitude easier (such as making random number generators more predictable). These kind of attacks are not protocol-specific and can be applied to SSL and PGP in equally successful way.


Why browsers don't support TLS without encryption and deprecate compression for public data These days we observes trend to use HTTP over TLS (HTTPS) for all communication. It recommend all weighty Internet service vendors and that claims to good practice. But TLS suite have 3 options for different purposes:

Certificate verification to ensure server authority.
Hash verification to ensure the HTTP package is not mangled by network equipment, Man-in-the-Middle, ISP, etc.
Encrypt data to hide it from reading for Man-in-the-Middle.

First two options makes sense for all type connection. But third makes sense only for sensitive data. Suppose user open public PR site or public library. What the sense add encryption overhead to that data? The same situation with TLS compression and regular HTTP compression in TLS channel. Compression deprecated due CRIME and BREACH attacks vulnerability of encrypted data and that may be used for public data.

In the same time common browsers don't support NULL encryption. You can ensure on ssllabs.com test

I checked Chrome/54.0.2840.100 and Firefox/49.0 and both don't support TLS_RSA_WITH_NULL_SHA or similar

public data doesn't mean no expectation of privacy when reading it: "how to deal with AIDS" maybe a public page, but readers may wish privacy.
If the website has cookies, they are probably not public data (auth cookies, obviously, but tracking cookies too for example)


If a provider sees the last 4 characters of my password, can they see it in full? I have some domains/websites as well as emails with Bluehost.  Every time I need support, they need the last 4 characters of my main password for the account.  They cannot tell me how they store the password, so  I am intrigued in how they could safely store my password(s) and still see the last 4 characters. Do they see the full password in plain text?

There's several possibilities.

They could be storing the full password in plaintext, and only
displaying the last 4 characters to the support person.
They could be hashing the password twice.  Once hashing the full password,
and again with just the last 4.  Then the support person types in
the last 4 to see if it matches the hashed value.  The problem with
this is that it makes it easier to brute force the full password
since the last 4 characters are in a separate hash, reducing entropy.
They could be hashing the full password, and storing the last 4 in
plaintext.  Obviously this makes it much easier to brute force the
password if an attacker gaining access to the password database knows     the last 4 digits.
Something else where the last 4 characters are stored in some way
that's discover able, such as encryption that Mike Scott mentions below.  If the secret to unlock the 4 characters can be discovered, this is as bad as plaintext.

All scenarios are very bad, and greatly reduce the security of the system.   It's not possible to know which scenario they're using, but each of them shows a lack of consideration for security breaches.  I'd advise caution if this is a site where you care about your account being breached.


How does security work in a cloud-to-cloud backup scenario? I'm thinking of using Spinbackup which is a cloud-to-cloud backup of gmail, but I was resistant to the idea of telling Spinbackup my gmail password for obvious reasons. However, on the Spinbackup security page it says this:

  Spinbackup never requires Google user credentials. We don’t store your
  passwords on our servers. It cannot access passwords as it uses OAuth
  2.0 to access your Google account data, the latest Google API, which allows two-step verification.

My common-sense reaction is that surely if someone has the privilege to back up my email, then that they can also read my email (and probably send email on my behalf too). Without going in to all the details about OAuth2, can someone explain what the above statement means and what security it offers?

How are they limited

Using OAuth, you ask for scopes, which are similar to permissions, this means they can only use the credentials for what they ask for, and cannot do things that are out of scope.

Some of the scopes do cover multiple things though, for example being able to copy an email means they can also read the email, which is not something that OAuth could defend against unless Gmail provided an encrypted access scope, but then if Gmail disappeared so would the decryption keys.

The benefits of using OAuth are:

You can revoke one app without revoking all of them
You can change your password without losing your apps
You can limit what apps do
Apps need to explicitly ask for scopes, so they can't escalate permissions

What do they ask for

Visually

Behind the scenes

Using data from the docs and a test login I found the following scopes are requested

email

View your email address
profile

View your basic profile info
https://mail.google.com/

Read, send, delete, and manage your email
https://www.googleapis.com/auth/drive

View and manage the files in your Google Drive
https://picasaweb.google.com/data/

This appears to be an old scope: Info
https://www.googleapis.com/auth/calendar

Manage your calendars
https://www.google.com/m8/feeds/

Manage your contacts
https://www.googleapis.com/auth/tasks

Manage your tasks

Conclusion

As you can see above, they ask for a lot of permissions, in theory, they could get away with the read-only variants of the above, but they may allow you to push data back to your account, which requires being able to write.


Is there any proof in support of these basic security guidelines? The Tech Solidarity organization provides a list of basic security guidelines, described by Jeff Atwood as

... pure gold and has been vetted by many industry professionals ...

From that same organization, there is also a list of Security Guidelines for Congressional Campaigns (april 2019).
Here are a few quotes from that document:

Uninstall all anti-virus software. ... The only exception is Windows Defender.

You must use an iPhone, model 6 or later. Android phones are not safe to use.

Use Google Chrome as your default browser on your laptop. ... Avoid Safari and Firefox

These seem like some pretty strong claims.
Unfortunately, no references are provided.
I've spent some time trying to find information that supports these claims, but what I've found seems either, old, inconclusive, or opinionated. For example, there's an interesting discussion about iPhone and Android phones here, but this does not deal with stock android. This discusses how antivirus software cannot protect against all threats, but doesn't say not to use any, and this explains how it is difficult to compare browser security.
Are the above guidelines all just opinionated, or does any consensus exist (among security experts) on these subjects?
Note, I'm asking for facts that either support or oppose these claims.

This group describes itself as:

Since 2018, the group has concentrated on fundraising from the tech community for candidates for public office.

It claims no knowledge about IT, but it suggests that its advice was found useful. Also, it provides advice for a specific group of people, in the quoted page, for congress members/candidates.
The reason why all the articles are inconclusive or heavily opinionated is that this is normal in our line of work. Very few read the IEEE transactions on computers or any scientific literature. And of course, many security incidents are not reported so statistics are not reliable. There is no real consensus on any of these subjects. For example: all anti-virus vendors produce statistics that anti-virus IS effective, with some underlying statistics.
Alternatives to anti-virus for keeping oneself safe provides a balanced view on anti-viruses.
It is a well-known fact that anti-virus consumes a lot of resources. That should not need any further proof. Others (like datapot.net) state, based on statistics that:

On average, antivirus software is only 25% successful at detecting malware.

Statistics on computer viruses and antivirus software show that, unfortunately, the malicious apps are winning the battle. Currently, “popular” malicious programs are having a field day, even against top-of-the-line antivirus software. There’s no such thing as a fully impenetrable wall; some viruses and trojans pass through completely undetected during the initial encounter with the antivirus.

The effectiveness of Code Signing seems mainly dependent on the signing process. Note that the enforcement of code signing is missing from the advice list given.
The bold statement:

Android phones are not safe to use.

is too general and the statement that IOS would be safe, is difficult to take seriously. Research Siri and its use of subcontractors to listen in, for example.
Browser advice seems more religious than based on reality. Real browser security seems more dependent on the use of plug-ins, Javascript (or, horror: still Flash!) and the likes. Note that ExpressVPN has a different view on the security; they have the following top 7:

Tor Browser
Firefox
Brave
Chrome
Safari
Opera
Edge


Security concerns about my webapp I read though OWASP very carefully, but I am not sure about some parts of my website.

I am using jbcrypt on my website. It stores the salt in the hash itself something like this hash+salt. I read somewhere that I should store the salt on a different database otherwise I would be vulnerable to rainbowtables again.
My framework is very new (Play! framework 2.x) and I have to do some cookie management. The framework offers signed sessions. However those "sessions" are no sessions they are only SessionCookies. Also I had to sign the cookies by myself.

The session cookie vanishes after the user closes his browser and I need a more permanent solution.

What i did:

If the user succesfully signs in:

I create a random string  and put in it my Cache randomstring -> user
I hash the random string an put it in a cookie.
Now if the user has a valid cookie, I will create a "session" from the cookie.

I am not 100% sure if this is correct, but this is what I thought would be correct.

Ressource : Is this approach of securing cookie secure? and www.OWASP.com

Now this part could be dangerous. I have a config-file in my sourcecode -> All passwords a stored in the same place.

I couldn't find anything about this. Where should I store those credentials like AWS-credential, db passwords, mail password ...?

No, this is not true, refer to this excellent answer for more details.
Can't comment on this as I have never used the framework before. Are you sure there isn't a way to set the expiry timing of the session cookie using the framework itself?
The config file should be stored outside the web root. See my answer here. The directory where it is stored should be adequately secured of course. Proper file permissions should be enforced.


Preventing CSRF with implicit flow and JWTs? I'm reading through openid connect document ATM and it says:

  Put into a browser cookie the ID token can be used to implement lightweight stateless sessions.

IIUC we want to avoid using cookies in order to ensure avoid CSRF attacks, since the browser will send the cookie with all requests, and if the user loads an image (While logged in to notsosecurebank.com) with the URL:

href="http://notsosecurebank.com/transfer.do?acct=AttackerA&amount;=$100">Read more!

The browser will send the access token (Since it's a cookie) and this allows the attack to happen.

If the token is storage in session or local storage and only sent via REST / XHR requests, then there's no way for CSRF to happen?  Did I understand this correctly?

Storing the token in the session or local storage is the solution recommended by OWASP.

However it is required but not sufficient to protect from CSRF: if an attacker is able to perform a Cross-site Scripting (XSS) attack on your site, the attacker could inject Javascript code that retrieves the token from storage and use it for undesired REST/XHR requests.

Follow the OWASP XSS Prevention Cheat Sheet recommendations too and you should be good.


How is the timer implemented in mutual distance-bounding protocols? I've come across several papers introducing the concept of mutual distance-bounding, where basically both sides can verify an upper bound of the distance in between, rather than having this unilateral relationship between a verifier and a prover. Although promising, these papers do not address the fact that in relay attacks the prover is usually an NFC capable card or chip. My question is, how can we implement a timer on this card to actually perform mutual distance-bounding protocols?
For reference, see Mutual Distance Bounding Protocols and SECTOR: Secure Tracking of Node Encounters in Multi-hop Wireless Networks.
This is a follow up question for Are there any transaction time constraints in EMV contact and contactless cards but in a broader context.

It is more important for the terminal to know whether a relay device is being used than it is for the card to know whether a terminal is being relayed. Most of the threats that use relays targets terminal's point of view to trick it into accepting fraudulent transaction.
In NFC payments, transaction always goes online verification by the issuer and regardless of mode, transactions can be always traced back to the merchant who was targeted by payment fraud. Securing terminals from fraudulent cards gives more payment protection than securing cards from fake terminals.
To counter relay attack, fixing either side can prevent relays. Distance Bounding Protocol requires to be installed in both terminal and card but the role of verifier can only be performed by the terninal as smart card does not have its own internal clock.
There is a patent available for Chip card device with real time clock for credit card. To count time, a clock doesn't have to be synchronised with real time. It only has to increment a counter for every second passed when provided power and then reset it for every transaction. But this requires changes to EMV architecture which can take years to standardize. Whereas Distance Bounding Protocol only requires changes to the software.
This company is offering next generation smart cards with built-in display, touch sensitive buttons and a real time clock with its ultra low powered battery which can last for more than 5 years. Theoretically, you can use any NFC hardware where ICC can be mounted. As Mutual Distance Bounding Protocols require clock for both parties, I don't think there is any way to verify relays from the NFC card itself without the clock.


How practical/important is the Lucky Thirteen TLS attack? I was reading this article which talks about a new attack against TLS being called Lucky Thirteen. It claims to allow repeatable MitM attacks against HTTPS connections.

It's described as being fairly impractical to actually carry out:

  Each tweak attempt causes a TLS session to terminate, which may be both noticeable and time-consuming.
  Each tweaked session needs to have the same plaintext at the same packet location for the tweaking to be done exhaustively.
  The authors needed 27 repetitions of an exhaustive set of 216 tweaks (that's eight million dud TLS sessions!) to produce enough statistically-significant timing data for a reliable result.

But there seems to be other voices that think it may become a practical, repeatable attack against HTTPS.

I was wondering:

How difficult it would be to take out of a lab environment into a known LAN, or from a known LAN to a WAN?
How difficult and how necessary would it be to defend against this attack given that I don't necessarily have control over the software? Are there methods of randomly padding and delaying HTTPS responses to avoid timing attacks?
How does this interact with current attacks against SSL/TLS such as BEAST? Does it provide an amplifying effect?

And most importantly:

How important is this result when considering future implementations?

I point you to this particular blog post by Matthew Green which gives a good description of the attack. In particular this quote.

  But there's no way this will work on TLS! It'll kill the session!
  Please recall that I described this as a practical attack on Datagram TLS (DTLS) -- and as a more theoretical one on TLS itself.* There's a reason for this.

  The reason is that TLS (and not DTLS) includes one more countermeasure I haven't mentioned yet: anytime a record fails to decrypt (due to a bad MAC or padding error), the TLS server kills the session. DTLS does not do this, which makes this attack borderline practical. (Though it still takes millions of packet queries to execute.)

  The standard TLS 'session kill' feature would appear to stop padding oracle attacks, since they require the attacker to make many, many decryption attempts. Killing the session limits the attacker to one decryption -- and intuitively that would seem to be the end of it.

  But actually, this turns out not to be true.

  You see, one of the neat things about padding oracle attacks is that they can work across different sessions (keys), provided that that (a) your victim is willing to re-initiate the session after it drops, and (b) the secret plaintext appears in the same position in each stream. Fortunately the design of browsers and HTTPS lets us satisfy both of these requirements.
  To make a target browser initiate many connections, you can feed it some custom Javascript that causes it to repeatedly connect to an SSL server (as in the CRIME attack). Note that the Javascript doesn't need to come from the target webserver -- it can even served on an unrelated non-HTTPS page, possibly running in a different tab. So in short: this is pretty feasible.
  Morover, thanks to the design of the HTTP(S) protocol, each of these connections will include cookies at a known location in HTTP stream. While you may not be able to decrypt the rest of the stream, these cookie values are generally all you need to break into somebody's account.
  Thus the only practical limitation on such a cookie attack is the time it takes for the server to re-initiate all of these connections. TLS handshakes aren't fast, and this attack can take tens of thousands (or millions!) of connections per byte. So in practice the TLS attack would probably take days. In other words: don't panic.

  On the other hand, don't get complacent either. The authors propose some clever optimizations that could take the TLS attack into the realm of the feasible (for TLS) in the near future.

You ask:

  How difficult it would be to take out of a lab environment into a known LAN, or from a known LAN to a WAN?

As the attack involves measuring very small timing differences, it might be slightly difficult to exploit outside a lab environment.

  How difficult and how necessary would it be to defend against this attack given that I don't necessarily have control over the software? Are there methods of randomly padding and delaying HTTPS responses to avoid timing attacks?

There appears to be little an end-user can do to defend against this attack. System administrators can help mitigate this by updating their SSL implementations, switching to the RC4 ciphersuite (as a temporary measure) and using AEAD ciphersuites like AES-GCM.

  How does this interact with current attacks against SSL/TLS such as BEAST? Does it provide an amplifying effect?

Like the team behind the attack suggested, the attack can be enhanced by combining it with BEAST-style techniques.

  How important is this result when considering future implementations?

The attack really is nothing new when it comes to theory, it is common knowledge that you should always encrypt first before applying the MAC.


Understanding blacklisted ciphers for HTTP2 I've been working on get HTTP2 support running on an Nginx server for some time now. At this point I'm stuck at selecting ciphers to support. Hopefully you can help me understand this.

Before I started with getting HTTP2 to work, I made it a hobby to get the best possible scores in SSLlabs while maintaining support for the majority of browsers. Thus, I only supported 256 bit ciphers and didn't list any 128 bit ciphers.

Since enabling HTTP2, I lost support for Firefox on Windows (and probably other browsers/platforms as well). Note that I'm fine having lost support for Java,  XP and Android 2.3 according to the SSLlabs browser simulations, as this is a private server.

According to SSLlabs, Firefox version 45 and 46 on Windows fail to connect to the server. The message shown is: Server negotiated HTTP/2 with blacklisted suite. According to the results, these versions of Firefox will have selected the cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.
A quick search led me to this topic on ServerFault that explained that the RFC specifies a blacklist of ciphers.

This is the cipher list I had configured:

ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:kEDH+AESGCM:CAMELLIA256:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!CAMELLIA+RSA:!AES128:@STRENGTH;

I'm led to believe that TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA is stronger than TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (which is used by Firefox in my current configuration), as it has a higher preference for Nginx if I add @STRENGTH to the ssl_ciphers directive. Still, the first one is listed in the black list and the second one isn't.

I'm aware that there are already some topics here about what ciphers should be chosed to get the best support. However, with this post I'm trying to better understand why some of the cipher suites listed above are blacklisted and several 128 bit ciphers aren't.

As the rfc4880 appendix you linked to says

  Note: This list was assembled from the set of registered TLS
  cipher suites at the time of writing.  This list includes those
  cipher suites that do not offer an ephemeral key exchange and
  those that are based on the TLS null, stream, or block cipher type
  (as defined in Section 6.2.3 of [TLS12]).  Additional cipher
  suites with these properties could be defined; these would not be
  explicitly prohibited.

Stream suites are blacklisted because the only stream cipher used in TLS is RC4 and attacks against RC4 have practically exploded in the last few years; see rfc 7465.

CBC suites are blacklisted because it is now recognized TLS-nee-SSL use of MAC-then-encrypt was a poor choice (although before the first clear recognition of this, Bellare & Namprempre in Asiacrypt 2000) partly because MTE combined with CBC (which requires padding) in an online protocol allows padding-oracle attacks like POODLE and Lucky13. POODLE severely breaks SSL3, but SSL3 was officially obsolete already and POODLE finally motivated people to eliminate it. Lucky13 requires precise timing and is not very practical now, but it shows an approach that might well improve. (SSL and TLS1.0 use of exposed IV for CBC also allowed BEAST, but that part is fixed in 1.1 and 1.2.)

Null ciphers are blacklisted because, well, their undesirability should be obvious.

This leaves only AEAD suites, and in practice only GCM, at least for now. Note that AEAD requires TLS1.2, which is not yet universally implemented, so generic tests like SSLLabs still accept CBC modes to allow for servers and/or clients using 1.1 and 1.0 (but not SSL3 as above). Chrome used to describe anything other than 1.2 with AEAD and ephemeral key exchange as 'obsolete cryptography', and security.SX has quite a few Qs about that, but on retest (51.0.2704.84) it seems to have stopped. HTTP/2, which comes along after TLS1.2 and AEAD 'should' already be in place, can reasonably be more demanding.

Unless we get practical quantum computers -- a very big unless people are now worried about -- the difference in strength between AES-128 and AES-256 is meaningless. It's the difference between 'unbreakable in our galaxy, but might be broken by someone controlling the entire universe for zillions of years' and 'unbreakable even in the entire universe'. No matter how perverse your collection of cat videos, you shouldn't care if it's decrypted after you're long dead, all your descendants are dead, all human beings are dead, and our planet and solar system no longer exist.

(Although given all the other media features added in HTTP/2, I'm disappointed they didn't add any capability to prohibit or at least seriously limit and degrade cat videos. Well, there's always X-.)


Are password managers more secure than a slightly different password for each website? Let's say I use a 5 word password composed of 4 words plus the name of the website I'm accessing. For example for GitHub, it would be something like "correct battery horse staple github".

How is that different to using a password manager with "correct battery horse staple github" as the master password?

I also have a simpler password for accounts I don't care about or that I suspect might be vulnerable. I assume that everyone but the major companies (Google, Facebook, GitHub, Apple) store passwords in plain text.

Am I at risk by using this approach?

Yes, decent password managers are more secure than using any password pattern.

You have a password manager, and it has created you random passwords:

6AKQ3)mcV!xX3b8-ZgncCe%tdn!&.@3X
a6/4TFaWKrzTHQyT2Df#;/*+QA$zH2tJ
9y__&%7jP4UcuG(9f7X6z44C#64bF:m&
9W649r788_8AU=9272zuGH"=C?2&C66j
nT29HMc$y'H)ww2#D/2x(2sBU#WG23us

Versus you have a pattern for your passwords:

correctbatteryhorsestaplegithub
correctbatteryhorsestaplestackexchange
correctbatteryhorsestaplegooogle
correctbatteryhorsestaplesomesite
correctbatteryhorsestapleapple

The site #4 has a bad practice of saving passwords in plain text, and their password database leaks. Now, from the latter it's possible to assume that this is a password pattern you use and deduce you might have correctbatteryhorsestaplegithub as your password for GitHub etc., but from the random password it's impossible to deduce the other random passwords, as they are completely unrelated.

On the other hand, if your computer gets infected and someone steals both your password manager database and the password (e.g. using a keylogger), they have keys to the kingdom. That's a completely different risk model and requires access to the operating system the password manager is installed on. Against this you need other measures like multi-factor authentication.


Microsoft IP Blocked by my fail2ban Yesterday at 3AM our Fail2ban blocked an IP, not tremendously uncommon, however it appears to relate back to a Microsoft address. This could perhaps be an Azure server being used for the abuse.

My main concern is exactly what it was attempting to do and if I should be concerned. Please see the below excerpts:

13.67.210.80 - - [08/Jun/2016:03:03:25 +0100] "GET /event/-1;select%20pg_sleep(6);%20--%20/admin/profile/ href= HTTP/1.1" 200 139
13.67.210.80 - - [08/Jun/2016:03:03:27 +0100] "GET /-1'%20OR%202%2b395-395-1%3d0%2b0%2b0%2b1%20--%20/edit HTTP/1.1" 200 139 "
13.67.210.80 - - [08/Jun/2016:03:03:23 +0100] "GET /(select(0)from(select(sleep(6)))v)/*'%2b(select(0)from(select(sleep(6)))v)%2b'%22%2b(select(0)from(select(sleep(6)))v)%2b%22*//
13.67.210.80 - - [08/Jun/2016:03:03:27 +0100] "GET /if(now()%3dsysdate()%2csleep(12)%2c0)/*'XOR(if(now()%3dsysdate()%2csleep(12)%2c0))OR'%22XOR(if(now()%3dsysdate()%2csleep(12)%2c0))OR%22*//

There are of course, many many other requests, most of which are 'normal' i.e not trying to inject any type of code, just attempting to edit sections of the site (with no results)

I have noticed several references to the web vulnerability company Acunetix, such as requests for:

 /acunetix-wvs-test-for-some-inexistent-file

So I can only assume, somebody is using their services to try and poke holes in our system.

My question is, what were they trying to do?, what can I do about this and should I even care?

Should I contact one of the above companies, or is this common occurrences?

Let it be banned. Unless you're a large company that has to worry about things like google e-mail servers IPs getting through, there's not much for you to worry about. abuse happens everywhere, including MS and Google. They should deal with it.


Disconnected wireless router security I've changed ISP and am using their router.  I wish to donate my old NETGEAR router still with its original Network Key (password).  Would someone obtaining this router somehow get access to my computer files and data even though I am no longer using that network or ISP? Thanks.

No.

If your computer is not connected to the router, other people having access to it won't be able to access your computer through it.

You could pose a convoluted (and highly unlikely!) scenario where a three-letter-agency recorded all your wireless traffic, then buy your router to attempt decrypt the messages that were sent in plaintext (ie. using only the Wi-Fi encryption) through that router in the past once they learnt the password you were using. This would require that they had recorded the initial 4-way handshake for that session, which requires being highly targeted. This would not allow decryption of anything you hadn't sent that session, or that were separatedly protected (eg. inside a HTTPS connection).


Blueborne - Attack Scenario Clarification Based on the Technical White Paper

http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper-1.pdf?t=1505319664351

After reading it, I understand it as follows (Page 13, bottom)

So to exploit (Linux kernel RCE vulnerability - CVE-2017-1000251), there are two actors Attacker and Victim

1) Attacker sends Configuration Request with EFS element with stype set to L2CAP_SERV_NOTRAFIC

2) Attacker sends Configuration Response with result field set to L2CAP_CONF_PENDING and possibly repeated parameters for example many MTUs values, to trigger stack overflow

I am confused since, since I thought the Victim should send Configuration Response based on Configuration request from the Attacker, but in the paper it is described as above.

Is this correct? Did I misread it? Can somebody expain/correct me on this?

Thanks,

Update 1:

When it helps somebody, here is a Conf Request Wireshark trace.

Have these 2 adapters

Client - 00:1A:7D:DA:71:13

Server - 34:F3:9A:10:52:C9

Here with the client I set MTU to 2000

./l2cap-client 00:1A:7D:DA:71:13
mtu: ok

./l2cap-server
accepted connection from 34:F3:9A:10:52:C9

Can somebody explain this? I have TCP/IP background ....

What does it mean localhost()?

Why it sends from localhost() to Client (Conf req) than from Client to localhost() (Redvd Conf Req) than Server sends to localhost() (Recvd Conf Req) and than from localhost() to Server (Sent Conf Response) is sent and at the end Client and Server send to localhost() Recv Conf Response - Success?

Update 2:

Found this, based on this each device should send a Conf Request and each request should receive a Conf Response.

Why it looks so weird than in my Wireshark trace?

Update 3:

Ok I think, I figured it out....

Attacker

Sends:

Sent Configure Request (DCID: 0x0040)

Attacker sends Configuration Request with EFS element with stype set to L2CAP_SERV_NOTRAFIC

Receives at the same time conf request from other party:

Rcvd Configure Request (DCID: 0x0040)

Sends:

Attacker sends Configuration Response with result field set to L2CAP_CONF_PENDING and possibly repeated parameters for example many MTUs values, to trigger stack overflow

Update 4:

Going to next step ... crafting the frames, here is my next questions if anybody is interested on SO:

https://stackoverflow.com/questions/46317365/bluetooth-reply-data-frame-using-l2test

Linux uses Bluz to implement the bluetooth stack which integrate bluetooth in universal socket communication.
So you can communicate with bluetooth device using traditional socket mechanism.
More details here: https://people.csail.mit.edu/albert/bluez-intro/x559.html


Are these cryptographic methods along the right track? I know we should never "roll our own crypto," but I want to understand the inner workings. I've written the following two encryption/decryption functions in PHP:

function encrypt($message) {

    $key = hash("sha256", base64_decode($secretpw64));    // get key from secret password
    $iv = random_bytes(16);                               // create an iv
    $output = openssl_encrypt($message, "AES-256-CBC", $key, 0, $iv);    // encrypt using openssl

    return implode(".", array(base64_encode($iv), $output));             // join iv.output
}

function decrypt($message) {

    $key = hash("sha256", base64_decode($secretpw64));    // get key from secret password
    $segs = explode(".", $message);    // separate the message
    $iv = base64_decode($segs[0]);     // get the iv
    $emsg = $segs[1];                  // get the encrypted message

    return openssl_decrypt($emsg, "AES-256-CBC", $key, 0, $iv);    // decrypt and return
}

I assume (which I know I should not) that random_bytes produces a crypto-safe random set of bytes, which according to the docs it does. I also use an Initialization Vector (iv) which causes the encryption to be different every time given the same input.

Is this code fundamentally flawed from a security point of view in any way? And, supposing it is not then is hash-then-encrypt (or similar) the next "level up" ?

There are some issues with your code.

$key = hash("sha256", base64_decode($secretpw64));

SHA-256 is very fast, and there is no salt here. An attacker can build a dictionary of (secretpw64, key) and get the key through a quick and dirty dictionary attack. As others have said, consider using a PBKDF. Even iterating the SHA for, say, 1000 times can be OK. For more information on how to derive a cryptographic key from a password, see this answer on Crypto.SE.

 $iv = random_bytes(16);

You are assuming random_bytes is a cryptographically secure PRNG, but this is not something you can handwave. Be careful!

Moreover, take a look at how IVs are generated.

If the application crashes, or you shut down the OS, and start again, is the first IV always the same? It could happen.

If it does, an attacker can crash the application and get two messages with the same key and IV whenever he wants. No need to wait for 2^64 messages!

Confidentiality is not everything in security. Integrity and message authentication are also important in most applications.

As it turns out, CBC is also vulnerable to bit flipping (aka byte flipping) attacks.

Basically, you can flip a byte in the ciphertext so to flip a corresponding byte in the plaintext. This normally scrambles the previous block, but it becomes a practical attack when you want to modify the first block and you can change the IV or, in some cases, by bypassing input validation. For more details, see this Defcamp writeup.

Finally, you should also consider other, non cryptanalytic attacks, depending on your threat model, including:

theft/disclosure of encryption keys (e.g. from the RAM);
malicious modifications or hijacking of the RNG. If, for example, an attacker can replace your RNG with a weak PRNG, everything breaks up.


Why does SSL connection does not fail after modifying the certificate in editor like VIM or Gedit? I want to fail the SSL connection between a server, hosted using openssl s_server command with a certificate issued by self signed CA, and a client(Browser). To do so, there are various ways:

Change the date of system which out of effective date of system; this way I am able to get an error in browser saying certificate is not valid for this date.
I tried to modify the server certificate in editor like VIM, to be specific I modified the CN( common name) field, because as per SSL standard CN must be verified to make sure that client is talking to actual server it wants to talk to, according to RFC 2818. Strangely, I observe that after restarting the server with this modified certificate client(Mozila Browser) is still able to establish a SSL connection with server. I don't get it how?

Ideally, as per my under standing if one single bit of certificate is modified certificate verification should fail, as client will calculate the hash of contents of certificate and compare it with decrypted signed hash from public key of CA, as certificate CN is modified hash of the contents of certificate will be different for sure.

Am I missing some important concept or I doing anything wrong in order to fail that connection?

In additon to this if I create a new certificate with different CN from same CA and use it inplace of original certificate then SSL conection fails saying Unable to communicate securely with peer: requested domain name does not match the server's certificate

Test Setup Information:

Created a self signed root CA, with private a key ca.key, and a certificate ca.crt
Created a private key named server.key; generated a csr for that private key CN as testserver.com; using self signed CA, signed the csr to generate a server.crt
Appended server.key and server.crt to a single file server.pem
Started a https server openssl s_server -cert server.pem -www
Added 127.0.0.1 testserver.com in /etc/hosts
Hit url https:testserver.com:4433` from firefox browser. SSL handshake is complete, and able to see cipher suite and session information
Create a copy of server.pem modified-server.pem, and edited the modified-server.pem's CN field to `invalidtestserver.com in vi editor and saved it.
Restart the server with modified-server.pem, with command openssl s_server -cert modified-server.pem -www and SSL handshake is still successful and able to see same output as previous one in browser.


Request signing for REST API I am building a REST API that will receive requests like:

GET /api/entities
GET /api/entities?filter=X&sort=Y

This seems straight forward: have the client HMAC(path + query, key), send me a key identifier and HMAC in a header or something, and then I do the same on the server to see if they match.

Here's my concern:

POST /api/entities

{ "foo": "bar" }

If the client computes the HMAC on that path and query, theoretically that HMAC could be used to submit any body.

tl;dr How would one properly implement request signing for GET, POST, PUT requests that may or may not have a JSON body?

You should HMAC the payload as well. Since you mentioned including a header with the HMAC of the path and query parameters, you could have a separate header that contains the HMAC of the body. However, you will likely only want one HMAC to be sent, so an attacker couldn't mix and match the different sections. Thus you could do something like this:

HMAC-Signature: HMAC( HMAC(path + query, key) + HMAC(body, key), key)

You may want to scrap HMAC all together and use TLS with client certificates. HMACs would be subject to replay attacks, unless you introduce nonces. Additionally, you have to consider that the HTTP spec can be hard to interpret consistently. Different browsers (and client libraries) have different approaches for things like character encoding. One application may want to send a?b=' but another may send a?b=%27, before decoding, these two resource/query strings will have very different HMACs.


Mutual SSL for clients of SaaS cloud service My company is launching cloud based SaaS service. There will be clients from different tenants connecting to our services via mutual SSL.

The clients would use a library provided by us to connect to the service. This Java based library would perform mutual SSL using keystores and truststores. So both server and clients are in our control. To emphasize, there are no browsers involved in the whole communication.

In order to successfully perform mutual SSL authentication, they must trust a certificate provided by our cloud service. This certificate could be:

A public CA certificate (like Comodo, Verisign etc.). But asking clients to trust a public CA would allow possibility of man in middle attacks as someone else can use a different certificate signed by same CA to fool the clients.
Private Root CA of our own. This would involve building our own PKI service and securing the private key et al. Does our situation justify opting this route?
Self-signed certificate used by both server and clients. One problem I see with this solution is that when the certificate expires, all clients across tenants will have to reconfigure new certificate at the same time. That would be unacceptable.

Another option I have come across is to use some sort of SSL pinning (certificate or public key) which will override the trust chain. This is not an easy solution to implement.

What is the recommended solution?

Given that both client and server are fully within your control I consider it the best (and maybe also easiest) thing to rely only on self-issued certificates so that you don't need to trust some external CA which is outside of your control.

If you have only a few communication peers it might be easy to go with self-signed certificates and exchange these when needed. Note that you could simply pin to the specific certificate or public key in this case and ignore any expiration, revocation etc - since everything is in your direct control anyway.

With more communication peers it is probably better to create your own PKI structure, i.e. have your own root CA which issues certificates for both clients and servers and which can also renew and revoke certificates. Once this PKI is setup the management of the communication peers is simplified since they only need to trust this specific CA (and only this CA). A simple PKI structure could be created with openssl already but there are also commercial products which might provide better usability and also scale better.

Given that you have full control over both clients and server it is actually possible to start simple and cheap (self-signed certificates), grow slowly but remain cheap (openssl based CA) and then move to an (not so cheap) enterprise CA when lots of clients are involved.


Does OpenSSL leave any traces that a server uses it? I was thinking that maybe the banners can give some insight as to whether a server is using OpenSSL.  Is there any tell tale signs that a server is using OpenSSL?

-- Clarification:

Speaking in terms external; as in, if I went probing around the web or Shodan, is there a way to identify servers that use OpenSSL?

To those who are wary, I'm just asking because I have to check if my servers are vulnerable;

-- Possible Method:

I found this on http://www.hacklabs.com/team-penetration-testing/2014/4/8/testing-for-the-tls-heartbleed-vulnerability.html:

$ openssl s_client -connect server.com:443 -tlsextdebug | grep “server extension”

Is this a method to identify if server.com uses openssl?

Some servers will advertise their OpenSSL version in the HTTP response headers from an HTTPS request. Example:

Server: Apache 2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o

These headers can (and often are) be disabled or not include this level of detail, so if OpenSSL isn't mentioned then it doesn't mean the server isn't using it.


client SSL authentication .pem file and .crt files So I have minimal knowledge of security really but I'm a primary developer on an application which handles some sensitive data that we want to be secure. The application communicates with one other server (the other server is the front end, my server is basically the backend). Our security expert (who is not currently available) has explained that we need mutual SSL authentication for the connection between the servers. Our sysadmin has setup client side authentication and given me a .pem file and now if anyone tries to access the application they get an SSL error because they are not passing client SSL authentication. I need to give 1 other developer who is in another state the ability to access the application. Can I just send him the .pem file (say via email)? Do I need to make a .crt file and send that to him? Basically what information do I need to give the other developer so that he has all the necessary information to access the application. What is in a .pem file? Just the public key or more than that?

PEM means Privacy Enhanced Mail, but the acronym has been long outlived by the file format. The "PEM" format is a method to encode binary data into text, so that the data may survive the transport through a medium which is text-based and not very careful with the data (typically emails).

Basically, PEM begins with some header:

-----BEGIN FOOBAR-----

followed by Base64 encoding of the binary data, and a footer line which marks the end of the element:

-----END FOOBAR-----

Therefore, PEM format is quite generic, and you have to look at the header to know what you actually have in the file.

In your case, you must make a distinction between the certificate and the private key. The certificate is the public part; it is something that SSL client and server send to each other during the initial handshake. Certificates can travel by email; since they contain only public data and are moreover signed, they don't need any extra protection.

Private keys are quite another business. In the SSL handshake, the client sends to the server a copy of the certificate (so that the server may learn what is the client's public key), and then the client demonstrates its mastery of the corresponding private key (internally, a signature is computed over a challenge from the server). The private key is what makes the client "special": the attacker does not know it. If the attacker knew the private key, then he could impersonate the client, and that's exactly what you want to avoid.

Therefore, sending a private key "as is" by email should really not happen.

However, in your situation, you want the client ("the developer in another state") to obtain both the certificate and the private key. You thus need a way to convey both the certificate and the private key to that client. The usual method uses the PKCS#12 format, which allows for password-based encryption:

Wrap both the certificate and its private key into a PKCS#12 file protected with a huge, fat, very random password.
Send the resulting file (conventionally called ".p12" or ".pfx") to the recipient.
Phone the recipient to give him the password, so that he may decrypt the package and thus obtain the certificate and private key.

If there is nobody available in your organization, who knows what a certificate or a private key is, then you have a problem. Namely, that you are using cryptography without understanding it. You had a "security expert" at some point: get him back. Security does not tolerate improvisation well.


What is the difference between cybersecurity and information security? I'm trying to differenciate between those two themes : cybersecurity vs information security.

Broadly speaking I'd say cybersec is about network security (TCP/IP, router, firewall,...) and infosec is about data security (data exfiltration, wikileaks like, ...). But I'm not from a security background so I can't be sure.

Also, what would be the difference between the activies of an hacker threatening cybersec VS an hacker threatening infosec. Hence what are some of the counter-measure and deterrence means in use in those two fields (cybersec and infosec)

Information security is data-centric, meaning about safeguarding data for the purpose of preventing unauthorized access, use, disclosure, disruption, modification, inspection, recording or destruction of information.  Information security is agnostic to the form the data takes (electronic, or paper).

Cybersecurity is about safeguarding information systems and the data they contain.  Cybersecurity is broader and includes 'Information Security' with respect to the protection of digital information.

Finally, cybersecurity is often modelled under 3 rubrics; security awareness; technology; and governance (or in different words, people, processes and technology)


unable to verify AWS EC2 Instance Identity Document with libressl I'm trying to follow the steps here:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html

to verify an instance identity document, and I'm getting success when I run on the instance (with OpenSSL 1.0.2k-fips  26 Jan 2017) and failure on my Macbook (with LibreSSL 2.2.7).

I've done a diff of the files and there's no difference. SHA1 included below.

Is there some obvious reason this would fail? Not really sure where to go from here.

On the instance:

[ec2-user@ip-10-215-73-128 ~]$ openssl smime -verify -in $PKCS7 -inform PEM -content $DOCUMENT -certfile AWSpubkey -noverify > /dev/null
Verification successful

[ec2-user@ip-10-215-73-128 ~]$ ls
AWSpubkey
[ec2-user@ip-10-215-73-128 ~]$ echo $DOCUMENT
/tmp/iid
[ec2-user@ip-10-215-73-128 ~]$ echo $PKCS7
/tmp/iid.pkcs7
[ec2-user@ip-10-215-73-128 ~]$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017

[ec2-user@ip-10-215-73-128 ~]$ sha1sum $DOCUMENT
0ab2144f3a388f9ab211fcc61b79d9c3996aae13  /tmp/iid
[ec2-user@ip-10-215-73-128 ~]$ sha1sum $PKCS7
986e701e30828217a3289a79df2759beda5eacc2  /tmp/iid.pkcs7
[ec2-user@ip-10-215-73-128 ~]$ sha1sum AWSpubkey
58f35f20bd57ec01773c29d08ff813c6b6479837  AWSpubkey

Locally:

$ openssl smime -verify -in $PKCS7 -inform PEM -content $DOCUMENT -certfile AWSpubkey -noverify > /dev/null
Verification failure
140735950726088:error:21075076:PKCS7 routines:PKCS7_verify:content and data present:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/crypto/pkcs7/pk7_smime.c:297:

$ ls
AWSpubkey   iid.pkcs7   instance.iid
$ echo $DOCUMENT
instance.iid
$ echo $PKCS7
iid.pkcs7
$ openssl version
LibreSSL 2.2.7

$ sha1sum $DOCUMENT
0ab2144f3a388f9ab211fcc61b79d9c3996aae13  instance.iid
$ sha1sum $PKCS7
986e701e30828217a3289a79df2759beda5eacc2  iid.pkcs7
$ sha1sum AWSpubkey
58f35f20bd57ec01773c29d08ff813c6b6479837  AWSpubkey

I believe this is a problem that occurs due to different error handling in old LibreSSL/OpenSSL versions. (Think MacOS really should have used something a bit newer for their defaults)

In old versions an error is thrown when a non-detached PKCS7 signature is given together with input content (basically it assumed the data wouldn't be referenced in both the signature and an external file). Later versions defaulted to only throwing an error if called with a flag or skipping the check entirely depending on branch.

You can try to fix this by verifying with an updated version of LibreSSL or OpenSSL. You can get these on your mac through macports or homebrew.


Does hashdump also dump domain creds when run on a domain controller If I understand correctly, meterpreter's hashdump dumps the content of the SAM file. Domain users should be in the AD database on domain controllers, which I understand is NTDS.dit .

On my test network, if I run hashdump on a domain joined workstation I don't get any domain users as expected.

However on my domain controller, running hashdump appears to also dump my domain users.

Why would people bother fetching NTDS.dit and using extraction tools like esedbexport + dsusers when they can just hashdump?

I fear I'm missing something. Could someone explain more clearly if hashdump on a DC does indeed dump all domain accounts and hashes, and what the difference is between that and extracting them from NTDS.dit?

smart_hashdump will query a Domain Controller's lsass to dump hashes, but the regular hashdump will only get what is available in the SAM database for users (usually IT admins) that log into the domain-controller server directly (whether on-console, via RDP, or some other remote mechanism).

domain_hashdump uses the NTDS.dit file to extract all Domain Users, including historical ones. See -- https://www.rapid7.com/db/modules/post/windows/gather/credentials/domain_hashdump -- for more information


Avoiding Wifi attacks I read that Wifi network cards when disconnected are constantly sending probes to check if any known AP is around.

This means that a hacker could capture those probes and simulate one of the requested networks and finally establish a connection.

Is there a way to disable this?
Wouldn't it be wise for the network card to ask which networks are up instead of calling them by the SSID?

Yes, this kind of attack has different names: Mana wireless attack, Yes Man attack, Probe Rogue AP, etc...

Your O.S. is sending constantly probe requests asking for one of your known networks. The attacker get this info and create a Fake AP with that info. Bear in mind is going to work only with Open wifis. Because obviously, the attacker is not going to be able to create one of your known wireless networks with the right WPA2 key.

So you can do different things:

Disable wifi if you are not using it.
Disable radio instead of disabling the card.
After finish using a public open network, delete the network profile in order to have only in memory secured networks that are not going to be cloned exactly.

The first two depends of your O.S. the third one is a good practice always.


Locking access to remote DB from a freely downloadable app (that acces the DB) If I want to publish a software that needs to interact directly with a remote database, I will have to put on the software all the required credentials and logic to have the access from the program itself. (No user identification required as it would be a public app and no intermediate servers)

With that software around "in the wild", with more or less difficulty someone can hack it and find the procedure to access the DB with the same rights.

Going more specific, the app could be some simple free game for mobile devices with  scoring and achievements in the remote DB.

What is a reasonable general strategy around this from a security point of view (if it makes any sense to go this route at all. Probably this question is so basic that I can't find a solution)

From a security standpoint you should limit the attack surface you are exposing.
As with most security features you should use defense in depth and have several security features in place like:

A web based API (like REST with JSON), being server over a TLS connection.
Limit allows values to a small set. (highscore is only numbers between 0 and 999999 for example)
Use Client side Certificates to limit abuse through simple means. (A determent attacker still can of course)
Use nonce in your API to prevent replay attacks.

There are propably more out there but this should give you an idea.


SSO authentication & authorization architecture/implemenation We got a bunch of different services (SPAs + API GW, legacy JavaEE apps, etc.). Each of those is usually ran in multiple instances (customer specific instances). The plan is to federate them under a single-sign on.

We also need to be able to authorize a single user to different set of roles in those applications - RBAC.

Eg.

user A can access only invoicing module of app X, is a regular user in instance Y of app Z and is an admin in app Q.

So we need to manage a set of groups (roles) to every user.

In order to keep the users manageable, the users/group storage should be central (a LDAP?). The roles in each application are specific, so it could be managed within each app.

What is the suggested architecture?

LDAP synced with a central Identity Provider?

Technology OpenID/JWT tokens? SAML claims?

So far we have experimented with a few OpenID providers. These seem to treat the authorization part (groups/roles) as a second class citizen a bit.

The identity providers usually do not enforce restrictions themselves. That's why your impression is correct that the authorization part is not implemented in IdPs. They rather deliver role/group/permissions information to the application (service provider, SP) so the SP can enforce authorization.

Most IdPs can access a LDAP server to retrieve user accounts, their group membership and check the user's password. Using an LDAP server has the advantage that some applications not capable of SAML, OpenID Connect, etc. might be able to directly use an LDAP server.

Managing even application-specific group membership is very helpful if you have to provide data to be examined during security audits. So I would try to keep group maintenance out of the application.


Can I restrict a Certification Authority to signing certain device/application? Basically another administrator wants a subordinate CA certificate for their fancy appliance. How do I restrict the subordinate CA certificate issued to them only able to issuing for their usages and not allowing them to issue certificate that are used else where.

Having subordinate CA that is not under control is pretty risky, I need to make sure that the sub CA will not cause damange to the PKI system.

Is there some policy that I could set in the Sub CA for the restriction ?

There are a few options that may help you here, but there's no guaranteed way to stop this:

Depending on your infrastructure, you may be able to use Name Constraints to limit your other administrator's CA to a specific subdomain or to a specific Distinguished Name arc.  Whether that helps you or not, depends on your specific circumstances.  For example, if your colleague's application is running within their own specific DNS subdomain, you could limit the new CA to this.

Certificate Policies may help you, but only if all clients can be mandated to check them.  This is not the case with the most common certificate usage - HTTPS; so again, depending on your circumstances, this may or may not be useful.  You would have to ensure that you're colleague's application clients check policies and also ensure that their developers don't disable it - this relies on you trusting the team.

Finally, and most importantly, PKI works only because all the CAs follow strict policies and procedures.  Without these, it is simply a clever mathematical conundrum.  Trust is only gained by ensuring that all participants play by the rules and follow your strict policies.  If any CA fails to play by the rules, they risk having their CA certificate revoked by the a superior CA - I'm assuming that is you here.  This is probably your best option.  Show your colleague your Certificate Policy document; ensure they understand them and write a Certification Practice Statement to that effect and hold them to task if they don't play by the rules.  If you don't trust them, don't issue them a CA certificate - it's your PKI's reputation on the line.


How do I implement Multikey encryption? I'm looking for an algorithm, by which I can encrypt a piece of data with n keys and that to decrypt I can use any of them.

I think I remember bitcoin using something similar for blocks, but now I cannot find something to use.

It's fairly easy:

Generate a master key with which to encrypt the data.
Generate a user key for each user that you want to be able to decrypt the data.
Encrypt the master key with each of the user keys and store all of the encrypted results.
When you want to decrypt, use the user's key to decrypt the encrypted master key record and use that to decrypt the data.

If you're using 128-bit keys with AES, you can simply use AES directly without a block mode (ECB if one is forced) to encrypt the master key with each user key, because the key fits perfectly into one block size. If you're using 256-bit keys, you should use a block mode such as CBC and store the IV alongside each record for decryption.

Keep in mind that such a scheme does not allow for access to be securely revoked from a user without completely re-encrypting the data, as a malicious user could keep a copy of the master key. Additionally, this will not scale very well for lots and lots of users (e.g. thousands), as your key set ends up being very large.

For encrypting the files themselves I recommend AES-CBC if tampering is not a concern. You can store the IV in the clear with the file data. If tampering is a concern then you should consider an AEAD mode which prevents meaningful tampering with the file data.


Why is there no referer when pointing to a secure page? I participate to a bug bounty program and try to find serious vulnerability to expose.

Firstly, I found that the company was not using CSRF token, instead of that, they use Referer to ensure the request is made from https://example.com.

Referer tend to be less secure than CSRF token, that's why I started to search for Open URL Vulnerability. After a few hours of search, I finally foud one. An input like https://m.example.com/?app=desktop&location=/admin?doSomeAction=stuff will result in the following Location header : Location:https://example.com/admin?doSomeAction=stuff.

Reading Wikipedia about Referer and https, I noticed the following line :

  If a website is accessed from a HTTP Secure (HTTPS) connection and a link points to anywhere except another secure location, then the referrer field is not sent.

As I am being redirect to a secure location, why is the Referer header not send when accessing Location:https://example.com/admin?doSomeAction=stuff

Edit : Browser does not change Referer on Location redirection. I got confused due to this post : https://security.stackexchange.com/a/24404/110133.
Now I wonder, if instead of Location, the page was sending content with <script>document.location="https://example.com/example.com/admin?doSomeAction=stuff"</script> would it change the referer ?

Actually the HTTP referer is not a mandatory header. The client can decide to leave it blank, or to send false information. I noticed Google Chrome does not always send the referer, and when it comes to HTTP -> HTTPS links, nothing is send for the first few requests. My best guess would be to say that the browser makes sure all the requests have at least been requested once over HTTPS, before the referer are added. Other options from this post:

It will/may be empty when the end user:

entered the site URL in browser address bar itself.
visited the site by a browser-maintained bookmark.
visited the site as first page in the window/tab.
switched from a https URL to a http URL.
switched from a https URL to a different https URL. (Some browsers)
has security software installed (antivirus/firewall/etc) which strips the referrer from all requests.
is behind a proxy which strips the referrer from all requests.
visited the site programmatically (like, curl) without setting the referrer header (searchbots!).

Update on comment

Yes I would expect it to change. For a browser it doesn't matter who triggered the location, you, a script, or a plugin, but then again, read the above.