AES128 and IV for app crypto We have some columns in some tables that are sensitive and would like to protect them "anyways". Also, since Azure SQL demands application level encryption, we have to roll our own. There would be a single application-wide AES128 'master key' (=secret bits, stored/accessed securely only by application binary at runtime). Each row in each table would use it's own row-specific IV.

I'm looking for strong reasons anyone would want to vote against AES128 as a suitable cipher for the above (I think it is).

You are sharing IV: cells from a given row will use the same IV. This is bad. Don't do that.
You use CBC; this is a mode which is known to have a few security issues (in particular, it is sensitive to "how much random" the IV is), and it will involve padding (since CBC encrypts only full blocks, you have to extend the data elements to the next size which is a multiple of the block size).
If you modify one of the encrypted cells, then you must reencrypt it. If you use the same key and same IV, then you have lost (security wise). Therefore, you must alter the IV for that cell. If you use the same IV for the whole row (which is bad), then you must reencrypt the other cells of the row as well.
A MAC is needed if potential attackers could modify the data in place; it is not if attackers are assumed to be passive only. Note that an attacker could modify the encrypted data in order to observe how your system reacts, and try to deduce things about the encrypted data. As a general rule, you are better off with a MAC than without.

I would therefore suggest altering your scheme into the following:

Use an authenticated encryption mode with associated data which combines encryption and integrity, like EAX or GCM.
User a per-cell IV, stored in the cell itself. EAX and GCM do not need a random IV, only an IV which is never repeated (for a given key), so you could use a simple counter: maintain a system-wide global counter, incremented every time you need to encrypt a new cell value (when you allocate a cell, and also when you replace the contents of the cell); store the counter in the cell itself (that way, a 64-bit counter will be enough, no need to go to a full 128-bit value).
AEAD modes include an integrity check which is computed over the data which is encrypted and some additional data which you can choose (the "additional data" is used for computation but is not stored in the encrypted result; you must provide it again upon decryption, so that the integrated MAC can be checked). Encode in that "additional data" the row and column numbers for the cell. That way, an evil active attacker will not be able to silently swap cell contents (the MAC will be OK only if the cell contents are still where they should be).

Also, don't indulge in the "rotating master key" fantasy. The only reason why you would have to change the master key is in case it was stolen; and, in that case, you must change it right away for the whole database. No need for a smooth, gradual transition: this is an emergency situation. Therefore, no need to keep a version number for the master key. An identifier for the cryptographic algorithm, on the other hand, is a good idea; it can fit on a single byte (or even less than that).

Encrypt the binary data, not a Base64 encoding of it. Encryption output will be binary anyway. Applying Base64 on the input will just make the data 33% larger, for no good reason.


Non-profit on limited budgets looking for safety with VPN/TOR etc First off, thank you ahead of time for your patience.

We are a small non-profit with a 100% volunteer staff. We deal with children and some adults that suffer from Mitochondrial disease.

So, I was put in charge of trying to find how we can (with our limited funds)keep as safe as possible.

I'm currently looking into VPN's. We use to use Peoples Internet Service but there software keeps kicking us off. We also use a TOR browser and we are looking into TORguard.net as a VPN.

Is this the best way to go, with the limited funds we have? We are using Protonmail for our email.

Also, it seems that ATT is starting to implement new pricing structures that make you pay higher prices if you want complete privacy and no tracking! ABSURD. We are hoping this will be a work around, since we are limited in providers.

I'm not an IT person, so excuse me if I sound ridiculous.

Your help is deeply appreciated.  :)
-Stephie

Per xander and Goblinlord's comments, let's go over some of the technologies you mention.

VPN (virtual private network) solutions are used to create secure network connections over the public Internet. If you have more than one office location, or you have people working remotely from home or on the road, you use a VPN to enable secure communications between those users and your internal network. VPN technology presupposes that you have an internal network at some location, e.g. an intranet with email, file servers, etc. In this day and age of cloud-based services, it is entirely reasonable that a small non-profit might have no internal network resources except users' computers, in which case there might not be an especially good reason to have a VPN. If you have at least some resources on an internal network, a VPN is a must if you want to share those resources with remote users.

Tor, on the other hand, is all about anonymizing your Internet traffic, primarily to prevent people monitoring your Internet connection and seeing what places you go on the Internet, or learning your physical location using IP address geo-mapping.

Note that Tor alone is not enough to guarantee anonymity. You have to enforce very strict rules around application usage or your identity can still possibly be discovered. This is a very important rule because breaking it invalidates the entire purpose behind using Tor.

ISPs connect you to the Internet via dial-up, mobile, satellite, cable, DSL, etc. In most countries, any decent ISP should allow you to use Tor and/or a VPN without interference.

It sounds like you have an office. If so, I recommend a broadband connection from a cable or other provider in your area. Options vary widely by location so it pays to do your research. As a non-profit, you may be able to get discounted service from some providers, so that's worth checking into.

The torguard.net VPN service sounds like a secure proxy rather than a VPN, but I don't know enough about their services to give you an answer on it.

Lastly, per the comments, what are your goals? You say you want to stay safe, but what does that mean to you? None of these technologies will prevent someone on your staff from going to a malicious web site and possibly having their computers hacked. Staying secure means keeping up with operating system patches, browser and browser plugin (Flash) updates, using anti-virus software and most importantly training your staff not to fall victim to things like phishing attacks over email or the Web.


Personal computer - work VPN My employer provided VPN software on our personal computers (VPN Tracker 365).  When logged in, would my employer have access to my desktop files/folders?  I have no issue of having anything to hide, just general expectations and concerns about privacy.

It might, who knows?

You are installing a software on your computer. Except if you had the source of that software (that you audit, that is self-contained, etc.) and you compiled it yourself and you did the compilation on a trusted host with a trusted compiler (see the famous Thompson article on trust), you otherwise can not have any guarantee on what it is doing or not. If it is installed under an Administrator account/service (probably needed for a VPN), expect that it can do everything.

Even if you are installing things on your own computer and not one of your employer, you may still be mandated by some policies tied to your contract on what you can or can not do with your equipment using some of your employer resources (network, etc.).

If you would like to have some safeguards, you should use VMs or equivalent so that you can segregate your work from your non-work use cases on your own computer. Or equivalent technologies (ex: on Linux you have network and filesystem namespaces so you can restrict what a process sees on the system regarding files and network capabilities).


How should resource providers validate OAuth2 tokens? Resource providers often provide read and write access to resources.

A resource provider should therefore not only validate the token (is it expired? is it revoked? is it valid? does it contain the required scope?), they should also check the token's privileges (does use XY have sufficient privileges for reading or writing resource ZY?).

Until now I have used the following workflow:

Client receives an access token through the OAuth2 code grant.
Client makes a request on behalf of the user to e.g. GET /user_postings
The Resource Service (let's call it User Postings) validates the token by making a request to the Authorization Server, confirming that the token is valid. The Authorization Server additionally passes metadata like the token expiration date, the token's audience, the token's scopes and the token's subject (e.g. User XY)
The Resource Service now validates that the subject (e.g. User XY) is authorized / allowed to perform the request. For example by checking an Access Control List or similar. For Example: Let's say User XY wants to update a user posting by User AB. This would for example be dis-allowed by the Access Control List.
If validation passes, the Resource Server executes the request.

Is this a valid way of doing things or am I opening up attack vectors? Is it ok for the Resource Server to assume that the token's subject is the one to be considered the authorization request? Are there maybe best practices or standards for solving this?

I am currently confused, because I read OAuth2 is delegation only, not authorization nor authentication and that clients should not make implicit assumptions like "token XY belongs to user AB, so user AB is authenticated".

Any help is gladly appreciated.

RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage , Section 5: Security Considerations discusses some of the issues related to the use of bearer tokens. From section 5.2:

  5.2.  Threat Mitigation

  A large range of threats can be mitigated by protecting the contents
  of the token by using a digital signature or a Message Authentication
  Code (MAC).  Alternatively, a bearer token can contain a reference to
  authorization information, rather than encoding the information
  directly.  Such references MUST be infeasible for an attacker to
  guess; using a reference may require an extra interaction between a
  server and the token issuer to resolve the reference to the
  authorization information.  The mechanics of such an interaction are
  not defined by this specification.

In step 3 of your workflow you describe the resource service asking the authorization service if the token is valid. This is an example of using a reference to resolve authorization information. However, step 4 has the resource server validating the subject (e.g. UserXY). This is an example of encoding authorization into the token itself. This hybrid approach isn't a problem but you could simplify your design by picking one or the other.

Also, instead of using a token subject UserXY to impart all a user's authorizations to a single token, it may be better to use the principle of least privilege here and have the authorization server put specific authorizations (e.g., read UserXY email, compose UserXY messages) rather than giving access to anything UserXY can do.


For anti-CSRF, isn't a session id cookie in a hidden form field easier than a random token? I sometimes run into sites with CSRF bugs and I want to know the simplest way to recommend for the developer to fix it.  (i.e., if I tell them "Switch to a framework that has anti-CSRF protection", they won't listen.)

Anecdotally, it looks like most sites mitigate CSRF by including a random token as a hidden form field, and then rejecting the form submission of the token isn't present.  (And it usually looks hand-crafted, not inserted by the framework.)

I'm wondering why it isn't much simpler (and hence, much more common practice) to do "double-submit cookie" -- where you take the session id cookie and put it in a hidden form field, and then reject the form submission if the hidden field value doesn't match the session id cookie.

First, the problems with the "random token" approach, if your framework doesn't have it built-in: You have to generate a random value and store it server-side, and in your storage table it must be associated with the user it was served to.  When the form is posted, you have to check that the value is there, check it's associated with the logged-in user, and then delete it so it can't be re-used.  If you screw up any part of this, you've potentially created a security hole.  And, you might need to create a new database table for your tokens, which is just more cruft.  (Yes, I know you can do it using hashes and secret values, but that's also error-prone.)

By contrast, consider the ease of using the session cookie.  (You don't want to use an authentication cookie, because if the authentication cookie is stored in a hidden form field, an xss bug might be able to read it.  But session-id cookie is probably safe.)  ALL you have to do is store it in a hidden form field, and then check the value when the form is submitted.

So, I contend that IF the website in question has a framework that uses session cookies, I can tell them that the easiest way to fix it is by using double-submit-cookie with the "session-id" cookie, and to ignore all the webpages which usually start out by talking about how to protection against CSRF by using random tokens.

Am I missing something?  Does double-submit-cookie have some disadvantage?

I can't tell if you independently re-invented double-submit cookies and didn't think anybody'd thought of it before, or just didn't do any research on a well-known topic. https://duckduckgo.com/?q=double+submit+cookie+weakness&ia=web has no lack of results, including some from this very site (see Double Submit Cookies vulnerabilities and Is the double submit cookie pattern still effective?).

Your approach is slightly novel in using the session cookie (which you seem to think is distinct from an "authentication" cookie; I'm sure there exists a site that separates those but they're generally the same thing). The problem is, then you're exposing the session cookie to script (either via the DOM or by making the cookie non-httponly). This isn't the end of the world; indeed, it's pretty common to pass your session token as an HTTP Authorization: bearer header value that is set by script and avoid cookies altogether (this has the added advantage of being inherently secure against CSRF, since the browser won't automatically forward any authorization data; the attacker would need to already know it in which case they could submit the request directly). Also, by the time the attacker can read your DOM or document.cookie, there's a ton of other nasty stuff they can do; the httponly flag is a really minor patch.

A refinement of this pattern is to use a cryptographic hash of the session token, stored either in the DOM (usually in a hidden form field) or in script-accessible data somewhere. It can be a keyed hash (such as an HMAC), but honestly it doesn't need to be; the attacker won't be able to reverse the hash anyhow, and if they have the session token already they don't need to generate the hashed value because they can just send a GET request and the server will send the value back.

Normal double-submit cookies are weak as a CSRF mitigation because there are ways to plant a cookie, especially if the target site doesn't use HSTS. If the attacker can plant their own anti-CSRF cookie value, then they can successfully forge requests from the victim's browser by including that cookie value in the body, too. Using the session cookie works around this - the attacker can still overwrite it, but then they've de-authorized the victim's browser which kind of defeats the point of CSRF - but adding a single round of SHA-256 or similar on top of the session cookie lets the actual session cookie value remain invisible to script.


In openssl cipher suites, does AES128 imply AES128-CBC if another mode is not explicitly mentioned? For example (from openssl ciphers -v), for AES128, the output:

 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256

is given. Does Enc=AES(128) imply AES(128)-CBC? I am inclined to believe so as no mode is mentioned and the output from openssl list-cipher-algorithms shows AES128 => AES-128-CBC.

Yes. The OpenSSL names are slightly different to the standard names. The man page here has the mapping:

https://www.openssl.org/docs/man1.1.0/apps/ciphers.html

In particular see this:

TLS_RSA_WITH_AES_128_CBC_SHA            AES128-SHA

So the OpenSSL name AES128-SHA corresponds to the standard ciphersuite using RSA and AES-128 in CBC mode.


Protecting my encryption algorithm if the attacker knows the key Today our programming professor challenged us to make a text encryption program: we will hand him a program that only encrypts (not the source code), plus a ciphertext generated by it. We win if he cannot decrypt the given ciphertext. If the program uses a key or some other parameter necessary for the decryption of the ciphertext, we must provide it to him.

I wonder what options does he have to decrypt my ciphertext.

First of all, I guess he could decompile the program and discover the process. So I decided to make it with PHP in my webserver.

The second thing is, obviously I shouldn't use known/popular encryption methods. All he would have to do is try each method (using the provided key).

So it boils down to making something original I guess... or not. Nothing stops me from using several popular encryption algorithms. Perhaps I can even mutate the key every time I apply one of the algorithms.

I have seen this question: Is multiple encryption a good idea? - and it seems like using different encryption algorithms is not that useful - but in my case it seems like a good idea: how could he know I used AES then BlowFish then something else etc even if he has the needed key? Is my idea feasible for this challenge?

You are asked to provide a program doing the encryption but not the decryption. That means the obvious solution is to use asymmetrical cryptography. Any standard asymmetrical encryption algorithm will do.

You say:

  If the program uses a key or some other parameter necessary for the decryption of the ciphertext, we must provide it to him.

But you only stated that you had to hand in a program for encryption not decryption. Obviously with asymmetrical encryption the program you hand in for encryption will not make use of the decryption key.

If you had to hand in both decryption code and decryption key, there would be nothing you could do to protect your cihpertext. If you have to hand in only the key and not the code, this opens op a major loophole, you could take advantage of.

Many cryptographic algorithms include random looking constants. If you are free to design your own algorithm, the boundary between constants in the algorithm and the key can be manipulated as you wish. Take any standard algorithm call the constants in the algorithm the key and hand those over and call the key of the original algorithm constants (which will then be hardcoded in the decryption program, which you do not have to hand in).

That would certainly be bending the rules to your advantage, but it would still be within the word of the rules as stated in your question. Of course I cannot rule out the possibility that you accidentally worded the constraints differently from how it was intended, in which case this solution may not apply.

You also ask:

  So it boils down to making something original I guess

I would be surprised if that was the intention. Certainly coming up with an original algorithm is not considered to be the way in which security is achieved.

Maybe the professor wanted to make a point about the security about original algorithms by showing how all the original algorithms would be broken. However if that's the intention of the challenge, then the professor is running the risk that one of the solutions only has vulnerabilities too subtle for the professor to immediately exploit.


Why is a cookie's life extended after half the time has passed on a sliding expiration algorithm? I'm coding my sliding expiration algorithm for Bearer tokens to mimic what's done by Microsoft on their FormsAuthentication logic, and reading their documentation they say (emphasis added)

  When the SlidingExpiration is set to true, the time interval during
  which the authentication cookie is valid is reset to the expiration
  Timeout property value. This happens if the user browses after half of
  the timeout has expired

What's the reasoning behind waiting for that instead of just increasing the cookie's expiration every time a user browses a page?

No particular reason, it seems a good balance between updating it on every request and not leaving it too late that it expires before the next user action is initiated.

Take two scenarios with a 20 minute expiry.

A user visit of 9 minutes, * denotes a page view:

012345678901234567890
*      * *

This has the advantage of short visits not having to issue an updated ticket.

A user visit of 25 minutes:

01234567890123456789
*    *         *
               ^ as half the time has passed, a new ticket is issued to expire 20 minutes ahead:
               567890123456789012345
                                   *
                                   ^ new ticket....

This enables the user to continue browsing without having to log in again for longer visits.

As the server doesn't know about users browsing that are not making requests (page views in my example), only updating the expiry time after half of the duration seems a reasonable way of keeping sessions alive.


How secure is using Saving Session Feature on WinSCP? I ssh to my AWS instances via WinSCP and it has public-private key authentication, password authentication is disabled. All the sessions are saved on WinSCP, so I click on the IP of the machine and I get logged straight in without entering any information.

I am not considering the threats which require physical access of my laptop. But I am wondering if there are any known vulnerabilities or attack vectors specific to WinSCP which can leak private keys from my saved sessions?

Edit 1: The private key does not have a passphrase.

WinSCP stored site contains only a path to your private key file and no more.

So it is unlikely it can cause any vulnerabilities at all, except maybe by making the file easier to be found on your machine. However, that’s irrelevant if you do not consider threats which require physical access to your machine.


SecureData even for admins with external login Given:

A WebService which stores user Data and a server with a database.

A Administrator which can acces the sever wit hthe webservice and the server with  the database.

Foreach user is a dedicated database.

Aim:

Store the data in a way so that even not the administrator can access it with the secret of the user.

Thoughts:

To make sure that the Administrator can't access the data stored by many users the data can be encrypted with a user secret. and / or the database can be created with a derivation of the user secret as password.

The data can then be decrypted on the client side.

Question:

This works with common user logins so I could use the user password or a hash of it as database password  / Encryption.
But Is there a practice what to do if the user authenticates with a external oAuth Login (Google,Facebook,Github...)? In this case i don't have any secrets / password of the user.

For me it would feel a little awkward to ask him for a "MasterKey". Are there any experiences on this scenario or real world examples?

The rule is that if the data is in clear text at any moment on a machine it is accessible to the admin of the machine. Because by definition, an admin can use administrative tools and can read memory of any process or install spys on any network route.

Doing so without good reason is of course a professional fault and the admin can be fired for that, not speaking of legal actions, but technically it can be done.

The only thing that could be done here would be to have different administrative zones, and configure the system so that the database machine admins cannot access the data. For that, the main server should be distinct from the database server and the database should only contain encrypted data. It can make sense if you have an internal server but want to store the database externally for redundancy reasons. But a much more common use case would be to have an internal database, and only store encrypted dumps in the cloud.

TL/DR: if you cannot trust the admin, you cannot trust the machine, so the webservice should only process encrypted data, which means that you need something else and elsewhere to actually process, encrypt and decrypt the data.


"Tor Profile" folder in Brave Browser cache I am using Brave Browser Version 1.0.0 Chromium: 78.0.3904.97 (Official Build) (64-bit) on Ubuntu 18.04. The browser has an option,  open new private window with Tor . When looking into cache files today, I found a folder named "Tor Profile", and then subdirectories "Cache" and "Code Cache". They further have some subdirectories which finally have binary files, 'index' and 'the-real-index'.
I'm not sure about how the browsers function and whether this is shady or not, but why are these files even present on the system if they are related to what I browsed in that mode?

Note that no windows of that mode are active.

Brave developer here.  We do not try to conceal whether you have used Tor or not -- that would be a little difficult.  We do, however, avoid storing your private browsing history.  If you find evidence of your private browsing history stored there, please let us know or file a bug.

You appear to be using a slightly older version of Brave (1.0.0) from before we changed how private windows with Tor work, which fixed a number of bugs (including at least one possible leak to disk).  If you update Brave, the corresponding directory will be at .../Default/session_profiles/Tor Profile instead of .../Tor Profile.  There shouldn't be any private browsing history there -- but if you find any, we'd like to hear about it!


Disk Erasing Security - Odd Number of Writes As one can find in the Disk Utility/Erase/Security Options section, there are two options for erasing disks securely - zero out 7 times or zero out 35 times. Where these numbers come from?

The 7 and 35 passes very probably come from the paper "Secure Deletion of Data from Magnetic and Solid-State Memory" by Peter Gutmann. There, he described various overwrite patterns targeted at specific hard drive write encodings.

However, the paper, and the 35 passes, are now obsolete, as they were for old hard drive technology, as even the author readily admits. Nowadays, to delete a disk, a single pass with zeroes is enough. Even better, use the SECURE ERASE feature of all modern drives.

For more discussion see the Wikipedia article on the Gutmann method.


Why are two CSRF tokens (hidden field and cookie) necessary to mitigate CSRF attacks? I’ve watched the Pluralsight course on web security, which states that to mitigate CSRF attacks, the website should return two “paired” CSRF tokens to the client, one in a hidden form field and another in a cookie, that are associated to the user’s session. These tokens are issued whenever the user visits a page with, e.g., a form.

Now, since the attacker’s website can’t get the hidden form field token (same-origin policy), it cannot issue a valid request to the page containing the form.

But why are two CSRF tokens necessary in order to prevent CSRF? Isn’t the form field token sufficient by itself?

The pattern you are describing is known as "double submit cookie", and it is a common way to defend against CSRF. The point here is that it doesn't require the server to remember the token. The client sends the token in both a cookie and some other way, e.g. in a form field. The server checks that both tokens are identical.

This works because the attacker can not read or write the cookie, and hence can't reproduce it in the form field. That is why it has to be sent twice:

If there was only a cookie, it would be sent automatically on every request and provide no protection at all.
If there was only a form field, there would be nothing to compare it to and the attacker could just enter any value.

There are other defences against CSRF, that only use one token. The most common is to just store the correct value in a session variable on the server, and check that a form field matches it. No cookie is needed. However, this has the drawback that the server has to maintain a per user state.


Should we encrypt all REST API calls from a mobile device? I have a mobile application and the backend is hosted on a cloud provider. I would like to ask for feedback on encrypting all REST API calls that will be used to communicate with the server, if we should or we shouldn't do it.

Adding details:

< Certificate pinning is in place >

for example instead of having a proper rest object

{
   "name" : "username",
   "info" : "profile"
}

make it similar to this:

{
   "encryptedData" : "Mq6rTVdPP1YMlE9AxhnryIRX+JA9MfIXv"
}

and after decryption it becomes the model and the flow carries on, of course the response is also expected to be encrypted in a similar fashion.

Considering that TLS is in place with a solid configuration (i.e. certificate pinning), which I find no reason not to, you'd need to work out the business risk you're trying to mitigate by encrypting this information.

Ask yourself, what would you gain by doing this? What type of attack vectors are you mitigating?

How are you going to generate, distribute and manage keys, where is the code and keys that encrypt/decrypts the data? What happens when (not if) the keys are extracted [i.e. will you be using the same key for everything?]?


privacy - Which parts of URL is protected by HTTPS? Assuming the website I visit uses HTTPS, which parts of the URL is protected from the eyes of my ISP?

eg; https://subdomain.domain.com/path/file.php?param=value

I know that domain.com (and probably subdomain?) is known by my ISP.
What about the path, file and params?

Your ISP and your DNS provider are able to see that you are connecting to subdomain.domain.com, but neither are able to see the entire URL that you are requesting.

The first thing that happens is that your DNS provider will see that you are requesting the IP address that subdomain.domain.com points to.  So, if you are using your ISP's DNS service, your ISP will see that.

Next, your ISP will then see that you are connecting to the web server at the IP address that subdomain.domain.com points to.

Neither your ISP nor your DNS provider will see the entire URL that you are pointing your browser to.  The entire URL is sent to the web server only after the SSL/TLS connection to subdomain.domain.com is established.

Note:  Even if you use a DNS service other than your ISP's, your ISP is still likely to be able to determine the hostname (but not the entire URL) of the web server that you are connecting to.  Many IP addresses used by web servers reverse to the same hostname that forwards to this IP, so your ISP could conceivably do a reverse DNS lookup (for the PTR record) of the IP address that it sees that you are connecting to, and this would reveal the hostname associated with this IP address (subdomain.domain.com).  In cases where one web server is hosting many SSL web sites on the same IP, (which can be done if the web server is running SNI), your ISP could still be able to see the hostname that you are connecting to, because this is transmitted from your web browser to the server in clear text before the SSL/TLS handshake.


Mitigating XSS by ensuring no letter is after an angle bracket I reckon it is pretty safe to mitigate XSS by enforcing no letters/special symbols right after the < bracket. As specified in the HTML spec, the tag name should follow the < to form a valid html element. Is the simple solution able to mitigate XSS?

Assuming create html element is needed in our attack.

This is safe under two assumptions:

Browsers actually follow the spec.
You only insert untrusted data between tags.

As for #1, I tried recent versions of IE, Chrome and Firefox and they all seem to follow it. But back in the day browsers were very forgiving creatures, so there might be old ones around who would kindly assume you mean

As always, I recommend the OWASP XSS prevention cheat sheet.

Edit: You say no letters. As per this answer you probably don't want to allow <!, </ or <? either, since they could be used to start comments and close tags. Might not lead to XSS, but could still mess up your page with unexpected consequences.


protected code execution Is there ever going to be a processor or execution system that can execute protected code for very specific operations that heavily rely on shared secrets and authentication?

With the assumption that one could download a bit of encrypted code that only this processor has the correct private key to decrypt, and that key could potentially rotate with some frequency.

Code wise, a call would look something like, with the protected as a keyword that assumes the language/vm/etc could actually marshall/transfer and run this encrypt function within a protected space

  int transactionAmount=1; int transactionId=444555;
  byte[] data;
  protected { data = encrypt(transactionAmount, transactionId); }
  sendToServer(data);

You can do this today pretty easily by leveraging TPMs for key management and perhaps Intel SGX for a more protected execution space.

The problem with such systems is always scale of operation, management and reliability. It's trivial for me to write some code, encrypt it with your public key and send it to you, it's extremely non-trivial to do this for everyone.


FIDO U2F use over multiple devices for the same service I've been looking at the FIDO alliance's U2F specification and there's something which I can't seem to find documented.

If I was to use a Yubikey or something similar as part of the authentication when registering for a service on my desktop, how would I then be able to authenticate myself if I wanted to log in on my phone?

My understanding is that the private key would be stored on the current device when you registered and the public key would be provided to the service. This would mean that to allow me to authenticate myself on different devices I would need to copy the private key from my desktop to my phone

Is this correct or have I misunderstood something around the FIDO specification?

Nothing is stored in the Desktop in the case of USB Security Key Based FIDO U2F (Yubikey, PlugUp, HyperFIDO, IDKey, Neowave) implementation. There are other implementation (e.g. Entersekt) which are tied to the client computer.


Any reason not to encrypt a 32 byte value by XORing it with a PBKDF2 hash? Ordinarily I'd use PBKDF2 to generate a key which i'd use with AES. But seeing as the hash is going to be as long as the data I need to encrypt is there any disadvantage to just XOR'ing it?

My reasoning is if you can derive the hash you would have the AES key anyway.

*Just to add the reason I would use PBKDF2 is it has to use a user provided password. The data being encrypted can be considered random. I am also salting.

By using PBKDF2 that way, what you are really doing is turning PBKDF2 into a stream cipher. The three main problems with this idea are:

Use of PBKDF2 as a stream cipher has not been thoroughly investigated. It may be fine. Or not. Security properties of PBKDF2 have been analyzed for mostly short outputs only, and then, only as a KDF.
If you reuse the same password and salt, then you get the same output. In a stream cipher XOR-with-the-data mode, this is very bad if you encrypt two elements. In that sense, you have now merged the PBKDF2 salt with what was the IV for AES, thus conflating the requirements. You'd better make sure that your overall protocol deals properly with that. (In that sense, this is similar to using PBKDF2 to generate a key for RC4 encryption, because RC4 has no IV.)
PBKDF2 is made slow with iterations. It so happens that its processing speed is also proportional to the requested output length. If you use PBKDF2/SHA-1 and ask, for, say, 24 bytes, and use 10000 iterations, then you will actually pay for 20000 iterations. This can quick become intolerable for longer messages to encrypt. Take note that the attacker who runs a dictionary attack does not need to compute the whole stream; thus, you incur the risk of needlessly slowing the defender while letting the attacker run at full speed.


Is it a good idea to let a database do a password check? Setup

A server running a PostgreSQL database and an Apache with several php applications. Access to db is over the loopback interface. The db contains a table with the username and SHA-512-CRYPT password hash ($6$salt$hash).

Common solution

Applications read password from user, hash it and do a string comparison on the database. If strings match, user is authenticated.

My solution

The database has a stored function(or prepared statement?) check_password(user, password) which php applications query with SQL. So they send the user and password in clear and interpret the db's answer (e.g. rows returned). This has the advantage that I don't have to make sure that all the applications support the same secure hash algorithm and I can encapsulate the authentication in a single place in the db. The same could be done for password changes update_password(user, old_password, new_password).

Are there any drawbacks to this solution?

EDIT: Added clarification on stored password format.

The "common solution" you mentioned has one glaring and obvious flaw: it can't use salt. If your hash has a salt (it should), then you need to fetch the salt before performing the hash operation. And if you're fetching the salt, you should just fetch the hash result at the same time. In fact, the two are typically stored in the same string.

Ideally, you should fetch the hash from the database and perform the computation on it in your application. Your bit about not wanting to worry about your applications supporting your hash functions is odd. Applications typically lead, not lag, databases in technology adoption.

Your solution of putting the password checking routine in a stored procedure is a bit crazy from a scalability point of view; password hashing if done right is extremely processor and memory intensive. Dumping that kind of load onto your database is ludicrous.

Stored procedures push computation from the web server to the database server, as do complex SQL queries. While that's OK in theory, in practice your database tends to be the least scalable part of your whole operation. Web servers tend to be (should be if you do things right) completely stateless, so running ten webservers takes no more work than running two. Databases are not so simple, and scaling up your database is one of the most difficult and expensive propositions most small websites face. This is immensely more difficult if you use any sort of database-side business logic. If you want the thing to be scalable, your application server should contain logic and no state, and your database should contain state and no logic.


DMZ and mail servers I've seen a few DMZ related questions here in the past, but wanted to ask one directly related to email. I've done some research on this, but wanted to ask the forums opinion.

I know it's best practice not to have anything externally hit your LAN directly, but I've seen implementations where external hosted email is being sent directly into the LAN towards the internal mail servers. My gut was telling me this was wrong, but how does putting an external load balancer, or reverse proxy server add additional security? Is it because it's cutting the connection and starting it again from within these system in the DMZ? I was having problems understanding why this would be more secure, even though I'm more comfortable with it happening. Should there be filtering of the requests occurring here?

Also, I know that the DMZ and LAN should never speak (in theory), but how are internal resources supposed to access external mail? I've read that it's more secure if there's a separate DMZ for mail and that the LAN users should only have access into the the DMZ, not the DMZ into the LAN.

The theory is that traffic to the DMZ must be inbound. In that case, should something bad happen to the the DMZ host, the attack is contained within the DMZ.

This means that the connections from your LAN must be initiated in the LAN, which usually means some kind of push (to the DMZ) or pull (from the DMZ) operations. This is doable for mail but sometimes impracticable for other services.

In that case the DMZ is often seen as a "thin layer" which is in theory more robust (because it is lighter) and therefore potentially less prone to vulnerabilities (and hacks).

This is particularly true when you get the actual data from a mammoth service which should not be accessed directly. This extra layer also allows you to "break the protocol" (as you mentioned), which means that an attack which would have succeeded on the target host will not be doable on the exposed one (because of the architectural change which stops the payload on the first layer (which is not vulnerable to that attack)).


Can iMessages be fabricated? I am looking to understand if it is possible to create fake messages (Apple iMessages) that can appear to be messages that were created years ago?  I have read that using SQlite a person can modify and create messages.  Is that really the case?  And if so, how can you verify if those messages are fake?

If you can create iMessages using SQLite, then you need to root the phone. So if the phone is rooted, you can't trust these messages.

Another case would be if you rooted the phone and then unrooted it, this way one can perfectly fabricate it.

Another thing is analysis of the SQLite file. If you add records to appear as they are yeards old, but in the file they are added at the end, then you might conclude these are fabricated. This also can be sorted by redumping the SQLite file, so exporting it to SQL queries and importing into file again. This way records will look like they have been saved years ago.

So by unrooting the phone and redumping the sqllite file you can pefectly fabricate it. You would need to unroot in a way to not leave any traces of rooting.

Finally you would need to make sure on the flash there are no old copies of SQLLite file.


Verifying encryption in Facebook Messenger secret conversations I've just tried Facebook Messenger's secret conversations feature. I started a conversation with Alice on Facebook Messenger for iOS. I noticed the following in Facebook's online help, under the heading How do I verify that my secret conversation in Messenger is encrypted?

  Both people in a secret conversation have a device key that you can
  compare to verify that the messages are end-to-end encrypted.

  To verify that the conversation is encrypted, compare your device key
  with the other person's device key to confirm that they match.

When I tap through to the device keys pane for a secret conversation, I am presented with keys called "YOUR KEY" and "ALICE'S KEY". They do not match. The wording above implies to me that I should see two identical keys. Although if they are "device keys" then they should be unique to a device and therefore be different. I concluded the help's wording is just unclear.

On that same screen displaying the keys, I read the following message.

  Your key is the same for all of your secret conversations on this
  device. Alice's key should match the one on their device.

That seems to say that if Alice sees the same two keys on her device, encryption is "verified." So it seems that:

A device key is the public key of a keypair generated by the Facebook Messenger app.
By confirming with Alice that her device key is the one I'm using, I authenticate her public key and achieve the "verification" Facebook is talking about.

If all of this is correct, then I have to ask:

Is this verification process just here to provide some comfort? Or is Facebook Messenger actually vulnerable to MITM attacks? Do paranoid users require an already-secure channel over which to verify keys? Finally, how can I find out more about the implementation of Facebook's secret conversations?

Facebook Messenger uses the Signal Protocol. This is the same protocol used in Signal and WhatsApp, and works on standard public-key cryptography principles.

Your key is your own public key, which others can use to encrypt messages intended for you. Alice's key is Alice's public key you (or anyone else) can use to encrypt messages intended for Alice. The strings presented in the app are actually cryptographic signatures of these keys.

To verify that both you and Alice have the correct keys, you have to compare the cryptographic signature of your key on your device to the cryptographic signature of your key on Alice's device and the cryptographic signature of Alice's key on Alice's device to the cryptographic signature of Alice's key on your device. This should be done over a secure channel, e.g. by meeting with Alice in person and comparing the signatures visually.

When you have verified both keys, MITM should not be possible. This is of course assuming Facebook's implementation of the Signal Protocol is correct and secure.

You can also skip the verification entirely for what's known as Trust On First Use (TOFU). With the TOFU approach you simply blindly assume that the keys are correct the first time, and later if someone attempts a MITM attack, the app will notify you that the keys have changed.

There's a Facebook whitepaper on Messenger Secret Conversations here and a formal audit report of the Signal Protocol itself here.


Full disk encryption on dual boot system (Truecrypt/Veracrypt) I am looking to run my laptop system with a dual boot configuration (Fedora + Windows) with full disk encryption.

I have a laptop that I will be bringing with me while traveling, both domestically and abroad. For obvious reasons, I would like to encrypt the hard disk. The system in question has one 128GB SSD with both Fedora 27 and Windows 7 installed on it in a dual boot configuration.

In this configuration, the hard drive is partitioned as follows:

sda1 (500MB): Windows Bootloader (System Reserved)
sda2 (73.8GB): Windows System (C:)
sda3 (250MB): Grub Bootloader (/boot)
sda4 (39.8GB): Linux System (/)
sda5 (5GB): Linux Swap (/swap)

The boot process proceeds as follows:

 UEFI
  |
  V
 Grub -> Fedora
  |
  V
 WinBootloader -> Windows 7

In an ideal world, I would like to introduce a third boot loader, loaded before Grub, that handles the decryption of the system partitions. This way all the system partitions, including Grub, can be decrypted using one password.

Some notes:

While I described a fully installed and configured system, I can format and reinstall if necessary
Dual booting is a necessity as I need Fedora for work and Windows for CAD programs.
Platform-specific applications aside, personal user data (files, meta, etc) will be virtually identical under both OS's as everything is synced with cloud services
I would like to avoid using closed-source solutions (i.e. Bitlocker)
I would prefer to encrypt both OS's using one solution rather than having an independent solution for each
Hardware encryption using BIOS/UEFI is not acceptable as I don't want to risk losing data if my motherboard dies
The Vera/Truecrypt system volume encryption wizard (under Windows, it isn't available under Linux) claims not to support system volume encryption on systems with more than one bootloader
Vera/Truecrypt are the potential solutions I've found, but if there are better ones I am happy to learn

The Question(s):

Is what I am attempting possible? If it is, what are some resources that might help me implement it? Regardless of whether it is or isn't possible, is there a better solution?

In an ideal world, I would like to introduce a third boot loader, loaded before Grub, that handles the decryption of the system partitions

As this would be a nice solution, the problem is that a bootloader does not pass a mounted (decrypted) partition to an operating system. It is loading the kernel into memory, starting it and passing a few parameters to it. However, you can encrypt your Grub boot partition and embedded a crypto key into the initramfs for Linux and LUKS (GRUB early crypto disk feature [1]). You could probably implement a similar solution for grub & VeraCrypt & Windows, e.g., grub loads a crypto key file from the encrypted boot partition into memory and VeraCrypt using it later. In that solution, you only have to enter one password during boot. To the best of my knowledge, this does not exist. And if you have mounted your boot partition, your unencrypted keys lie on the partition. So your ideal solution would be only possible with hardware encryption/BIOS/UEFI today.

Alternatively, you could let one party do the encryption for both operating systems, but this only works with virtualization. E.g., you could install Fedora and Windows on a Xen Hypervisor and let Xen do the disk encryption. You probably need non-virtualized hardware in Windows for running CAD programs, but this is not a problem anymore with PCI pass-through [2]. This is pretty complex to set up and requires deeper knowledge in Xen but has the advantage that both systems can run simultaneously. The performance overhead with hardware virtualization is pretty small today. A good starting point is [3].

[1] https://wiki.archlinux.org/index.php/GRUB#Boot_partition
[2] https://wiki.xen.org/wiki/Xen_PCI_Passthrough
[3] https://wiki.xenproject.org/wiki/Xen_Project_Beginners_Guide


Are there virus scanners for Windows that can be run without installation? I wonder if there are virus scanners that can be run without installation.
It would be very practical.
Simply insert the USB pen drive and scan...

It would be good if the scanner also detects malware.

ClamAV a popular open-source AV scanner has a portable app version available on portableapps.com.  This should allow you to manually scan drives and files from the USB drive, but the always-on background scanner will not work as that requires installation.


Doesn't adding requirements to a password, such as must contain 2 digits, decrease the strength? Possible Duplicate:
  Doesn’t imposing a minimum password length make the password weaker by reducing the number of possible combinations?

Doesn't any constraints added to a password policy increase the ease of guessing the password (since a constraints shortens the domain of possible passwords)? For example a password must be at least 10 characters - attacker knows not to bother with passwords shorter than 10 characters. Passwords must have 2 numbers - attacker knows to only check passwords with 2 numbers. It certainly is common for policies to enforce users to have a mixture of characters and a minimum, why is this? Does it have to do with the has functions; for example if a string contains a mixture of letters and digits are collisions less likely or is the hash value harder to reverse engineer?

I think you may have missed a subtle part of the policy:

You must have a minimum length.
You must have a minimum number of letters.
You must have a minimum number of numbers.

From a purely statistical perspective, let's look at the possible reduction in keyspace. My apologies if it's a bit hard to follow, but you'll understand my reasons for it as you get towards the end.

First, we'll look at the possible lengths for a password. In theory, your possible lengths fit into the set ℤ+, i.e. all positive integers. This set is uncountable, i.e. infinite in length. As such, any set with bounds {n→∞} is always uncountable, as long as n<∞. So for any non-infinite length password your length requirement will not change the number of possible lengths. Let's define a function ƒL that gives us the length of any arbitrary password, for further use.

Next, let's look at the numbers of letters and numbers. Since the domain of our function ƒL is at most {1→∞}, and at least {n→∞} for n<∞, we know that it is uncountable. Computing the number of permutations for a character set C and a length L requires us to compute CL, i.e. C raised to the power of L - let's call this ƒS. We do this commonly for determining the number of possible values storable in an n-bit binary string, by computing 2n, so it should be a familiar task. Unfortunately, L in our case is not a defined number; it's a function. So we're really trying to compute C raised to the power of ƒL, which is rather meaningless since the output of ƒL could be any positive integer. However, we can observe the behaviour of this operation - since the outputs of ƒL are an uncountable set, any value of C would always cause produce an uncountable set too. As such, for any value of C, ƒS always produces an uncountable set, and therefore the keyspace remains infinite regardless of the character set, as long as the possible lengths of the password fit into the set ℤ+.

Now, all of the previous was purely theoretical, and largely nonsensical in any applicable way. In practice you couldn't allow a 2×10100 character password, so you do actually have a limit. As such, the set ƒL becomes countable, and therefore the set ƒS becomes countable too, and by definition is now dependant on the value of C. But to what extent does this matter?

The answer is not based in mathematics, and this is precisely why I've taken you on a circuitous and verbose route to this point. It's not about the numbers, it's about the people. We've seen, time and time again, the bad password practices employed by the masses. The password dumps leaked after breaches of major sites like LinkedIn, Sony and Gamigo have demonstrated how horribly common poor passwords (like "letmein" and "dragon") are. The holy grail of password policy is one that makes users pick passwords that are resistant to manual guessing and bruteforce attempts, yet remain memorable enough that the user doesn't have to re-use passwords. The holy grail does not exist. You cannot possibly make every single user adhere to perfect password policies.

Providing a password policy that brings some absolute minimum requirements (one letter, one number, minimum 7 characters) is enough to bring 100% of the offenders over to a non-dictionary password, 80% of them over to a non-common password, and kill off 90% of common passwords. That means you've successfully reduced your attack surface for low-hanging-fruit attacks by at least 80%, which is a big win. Furthermore, you've not dented your conversion rates on signup, since basic password policies are standard practice to most users.

So, whilst you may be theoretically reducing your character space, it's a poor measure of password security and a complete tangent to the real goal of increasing security. Password policies are about people, not numbers, and as such must be studied as a psychological mechanism, not a mathematical one.


Why does Windows consider a certificate valid even after its expiration time? I downloaded Google's Cloud SDK installer today, and upon checking the certificate to validate it, I noticed something strange: the expiration date of the certificate appears to be December 22nd 2019 - over four months from today, April 30th 2020. Despite this, however, Windows displays the certificate as valid and doesn't seem to care that the certificate is past its expiration date.

What is happening here, then? Why does Windows consider this certificate valid even though it expired four months ago? I was under the impression that certificates can no longer be trusted after they expire, and require a renewal. Is this not the case with software signing?

It's OK if the certificate has expired - as long as the timestamped signature on the file that you downloaded was made while the certificate still was valid.

See https://comodosslstore.com/resources/how-to-avoid-code-signing-certificate-expired-issues/ for more info.


How to recognize TOR traffic Having a PCAP file with TOR traffic, is there a way fast enough to recognize if any of the packets are part of TOR traffic/sessions?

Some tools speak about "protocol identification via statistical analysis", but I'm wondering if there are any technical details or packet attributes to identify TOR traffic.

Incoming TOR traffic is easy to recognize because all TOR exit nodes are publicly known. That means you could search by IP of exit nodes. But this traffic is actually not really considered as TOR traffic because it already left the TOR network. It's just traffic that comes from TOR. It might not even be encrypted.

Outgoing TOR traffic is much harder, if not impossible to recognize because not all entry nodes are publicly known. You could search by IP of some entry nodes of which you know the IP, but that would not cover all TOR traffic.
I think China is the best example for recognizing/filtering outgoing TOR traffic. As far as I know, they are the only country that successfully (or at least partly successfully) blocks TOR by using protocol analysis. Because of that, TOR created special algorithms for obfuscating TOR traffic in order to get it through China's great firewall. But it's a cat and mouse game. The obfuscated traffic is also recognized and blocked after some time, and then new obfuscation algorithms are developed. That's why it's so hard to block outgoing TOR traffic.

I do not know much detail about how China's traffic analysis works. Perhaps, no one here knows for sure, but maybe someone could give a guess, although it's probably not a simple procedure.


Is it possible to perform second order SQL injection with email addresses? Let's imagine a website which allows users to Sign up and login only with their email address.

Is it possible to perform a second order SQL injection in that case?

It's possible to perform a SQL injection attack anywhere that the system places user defined data (in this case the username) directly into a SQL query without first sanitising it.

So, the answer to your question is yes, it is possible, depending on the behaviour of the system in question.


How Anti Phishing in Google Safe Browsing works? As the question says, can anybody give insights on how anti phishing works in Google Safe Browsing?

Does it just use a database of detected phishing URLs or does it use any heuristic?

Google Safe Browsing just checks against a database provided by Google if the visited URL is potentially malicious. There are no heuristics employed by the client using Google Safe Browsing but instead every intelligence is in the crawling and classification process done by Google.


Where/what is the actual HeartBleed bug? I've read lots of reports of the HeartBleed bug but have not been able to find a description at the source-code level, such as this one for the goto fail bug.  Can anyone provide, or point to, such an explanation?

The blog existentialize did a simple, easy to read writeup.

The basics are:

unsigned char *buffer, *bp;
int r;

/* Allocate memory for the response, size is 1 byte
 * message type, plus 2 bytes payload length, plus
 * payload, plus padding
 */
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;

Allocate what the requestor asked for.  Without zeroing it out.

/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);

Copy the sender's payload to send it back to them.

Except... the sender didn't send a payload.

Directly from the blog: "What if the requester didn't actually supply payload bytes, like she said she did? What if pl really is only one byte? Then the read from memcpy is going to read whatever memory was near the SSLv3 record and within the same process."


Prevent all Firefox Addons from sending data Firefox addons are known to send data (like the URLs visited, location, installed cookies etc.) to their maintainers and (from there) to third parties. See for instance the newest "scandal" about the WebOfTrust addon (link is in German):

https://www.kuketz-blog.de/wot-addon-wie-ein-browser-addon-seine-nutzer-ausspaeht/

Since, on the other hand, addons are also essential to prevent tracking activities (e.g. the well-known NoScript addon), simply disabling all addons does not seem to be a good solution to protect one's privacy.

What I'd like to do is: Keep my privacy protecting addons, but somehow (maybe through Firefox internal settings in the about:config dialog or some hack to Firefox or indeed to the operating system, Debian 8 in my case) prevent all Firefox addons from sending data from my computer to the internet. Obviously, this should not be achieved with yet another addon, then we've come round in a circle. (As a downside I realize that this will also break auto update of these addons, and maybe even their normal functionality. But in the latter case this would be a reason for me not to trust them any more.) In fact, I'm using Iceweasle on Debian 8, but this is synonym with Firefox, I think.

(An alternative would be to review the source code of the addons myself line by line and then - after convincing myself that they do nothing more than I expect them to do - compile them myself. But since I am not an expert in this field (I don't even know how to compile a browser addon) and since some addons try to obscure their activities deep inside the code, see for example:

http://www.howtogeek.com/180175/warning-your-browser-extensions-are-spying-on-you/

the blocking of outgoing traffic initiated by addons is probably more practical in my case.)

I doubt that this is possible or at least such restrictions could easily be bypassed by add-ons. Many useful add-ons like ad-blockers need to make changes to the site you visit. By doing this they could also inject new code into the original site. This code is then executed in the context of the visited site and not of the add-on and thus any restrictions setup for the add-on itself will not apply, like the restrictions to phone home.

Apart from that in the specific example of the WOT extension (web of trust) you cite the user explicitly installed an extension which sends each URL to some server to get the reputation back. Blocking this communication would effectively cause the extension to stop working since it cannot get a reputation any more. This means simply blocking communication is not an effective way of stopping such privacy problems in all cases.


OWA Keep-Alive in http, even though it should be forced https Yesterday, I got an alert from a client's IDS that a Base64 auth packet was detected.  Looking at the ASCII decode, I can see that it is for their OWA (Outlook Web Access), and indeed, the auth info was Base64, easily decoded to the username/password of a user.

What is odd, is that this company's Exchange server is setup to never allow connections unencrypted (via HTTP or POP/SMTP). It will always redirect http to https before authentication is required.

Since getting this alert, I have queried for other alerts of the same kind, but cannot find much more... It seems to be an edge case.

Any ideas on what is going on?

=====Ascii Decode of packet====

GET./.HTTP/1.1
Host:.xxxxxx.com
User-Agent:.Mozilla/5.0.(iPod;.CPU.iPhone.OS.5_0_1.like.Mac.OS.X).AppleWebKit/534.46.(KHTML,.like.Gecko).Version/5.1.Mobile/9A405.Safari/7534.48.3
Accept:.text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Authorization:.Basic.xxxxxxxxxxxxxxxxx==
Accept-Language:.en-us
Accept-Encoding:.gzip,.deflate
Cookie:.UserContext=ecc88b90b86c483f89db34eb673c259c;.OwaLbe={A907E8ED-3881-4B44-B84E-F036E6485722}
Connection:.keep-alive

About that Base64 auth packet, it is related to this discussion in the McAffee communities
here. This is because, they have set Basic Authentication mode for OWA.

The isssue is explained in detailed, some of the explanation:

  Basic  Authentication is a means to send usernames and passwords over the network to log into a device upstream.
  This form of authentication is inherently insecure because it is sent in plain text over the network, however, it is widely adopted
  by most clients/servers which still makes it relatively popular, especially in multi-platform environments.
  We strongly suggest that if you are going to use it, then you should use it over
  HTTPS (SSL/TLS), to prevent anyone from using a packet sniffer and picking up passwords while in transit.

  Basic Authentication is simply a base64 encoded username/password sent across the wire as
  user_name:password

  To base64 encode a username and password:
  echo -n "valid_user_name:valid_user_password"  | openssl base64 -base64

With regards to the unencrypted HTTP communication, it could be a flaw with the ActiveSync implementation on IOS 5.0.1. Or related to this MS support ticket that said:

  The new functionality sends HTTP requests even when the client is idle. The client sends a keepalive request (/owa/keepalive.owa), and then the client sends more information about the activity of the user by adding the following path of the published OWA URL:
  /owa/ev.owa?UA=0

I wonder why MS did not say it sends HTTPS request??? More test need to be done. And this is only related to Exchange 2010 new OWA functionalities.


What will happen to older browsers if I disable SSLv3 on my webserver? We have a public facing e-commerce web site. Our credit card payment provider has told us they won't support RC4 encryption anymore. They said that users with older browsers may or may not be able to place orders on our site.

If we disable SSLv3 on our website, what will happen to users with an older browser when they try to access the HTTPS pages?

If you disable SSLv3 on your site, then older browsers that do not support TLSv1 or higher will not be able to connect to your site by SSL/TLS.

Having said that, SSLv3 has been deprecated for some time, thanks to POODLE.  As a result, many web sites that employ SSL/TLS have stopped supporting SSLv3 for a while now.  So, users that are still using older browsers that do not support TLSv1.0 or higher are likely to be having problems connecting to many sites by SSL/TLS (in addition to yours if you've disabled SSLv3).

In fact, in addition to the payment card industry (PCI) requiring sites that accept card information to disable SSLv3 - they are in the process of mandating that these sites phase out support for TLSv1.0 as well.  Soon, all sites that accept card information will be required to support TLSv1.1 or higher.

Edit:  See this Wikipedia page for a good reference on SSL/TLS protocols supported by various browsers.


Can SIM card be locked to the specific equipment? I'm curious if SIM card can be "personalized" to operate only in the specified mobile equipment in addition to usual PIN security. So the SIM extracted from "legitimate" phone and placed into arbitrary one won't reveal it's data.

I realize what SIM is JavaCard-based smartcard, so in theory this kind of mutual authentication might be possible.

Store the IMEI of the equipment in the SIM card applet.
On start of the mobile equipment, just check if the IMEI of the equipment is the same as that of the one stored in the SIM card applet. By comparing both, you can take a decision to update a memory byte in SIM card, which will eventually make it disable for the operation. Refer ETSI 11.14 Standard.


Reverse-engineering password salts Lets set out a scenario, a database has been dumped and all the passwords are hashed.

You notice that some users seemed to have signed up twice and have the same hash.
You run these hashes through your hash cracking program and nothing comes up, presumably because they are salted and you don't have the salt. But because users have the same hash on 2 accounts the salt isn't going to involve any random values, correct?

If the site was still vulnerable and you were able to create your own account and retrieve your own hash would you be able to reverse-engineer the salt given you know the password you signed up with?

Disregarding collisions, two users having the same hash value means that both of them have the same password, salt, and pepper. Consequently, this usually means one of two things

The site uses a fixed salt for all users: This renders the scheme to a pepper-only password hashing scheme (the "salt" is in the code). By means of brute force, and by employing knowledge of a plaintext password, you can find out the value of said "salt".

This, of course, can be done by registering another account of your choice and attempting to brute-froce something like hash(password + X), with X being the value you want to find out, and then comparing the output to the hash you extracted after creating your new account.

A site doing something as stupid as using a hardcoded salt (pepper-only) will probably be using something like MD5 or SHA-1, which will make your brute-force attack much faster.
The site uses non-unique salts derived from certain information from the user: (username, email, etc.) which you can find out by means of brute-force.

Since the database you extracted didn't contain any salts, it is most likely the case #1.

Note: Just because a duplicate hash wasn't found in rainbow tables, that doesn't mean it's an easy password. It might be the same user with two accounts using the same strong password.


What's the advantage of passing credit cards via javascript vs. over the server (without saving it)? I've noticed current credit card gateways like stripe and wepay encourage sending the credit card number via their js framework (which would use some iframe jsonp magic to pass the data).

To my knowledge this way you don't need to worry about much of PCI compliance other than using SSL.

I understand that storing it can lead to many issues, from how it's stored (strength of encryption) to protect from employees access to the database, to protecting the database from SQL injection etc. But if it's not being stored, how could the data be compromised? If I'm worried about someone getting into my server and modifying the files to direct the data to themselves, then it won't make a difference what my code is.

My question is, what indeed are the security risks by having my server send the cc info (even without storing it) over having it sent by the browser/client?

The risks are more on the client end of things than your server side. What I mean by that is as a consumer I do not want my data going to your server for "processing" which then gets sent over to stripe/wepay. I dont know how you're transmitting the data or whether or not you're not storing it the way you say you are. Also from the consumer side of things if you're not PCI compliant I wouldnt go near your systems.

If you did however want to do the processing you'd have to find a server side library (of which ive not looked into) and make sure the data being passed is sent securely from the client to you and from you to the transaction handler.

The risks are the same on both sides, MITM. If I know my connection to the service is safe why would I risk using your system as a MITM?


What is ("ASCII" redundancy) which is said to be required to retrieve the original plain text in 2 times pad? Sorry for the long title :$

In a video speaking about attacks on the one time pad which uses psudorandom generators (PRG),
It's said that Eve can retrieve the plain text of 2 messages that have been encrypted using the same key by XORing the two resulting ciphers .

The lecturer said : "since ASCII has enough redundancy it is easy to retrieve m1 and m2 from the string (m1 XOR m2) " .

What's the meaning of enough redundancy ?

It is not really the redundancy of ASCII, but the redundancy of that which is encoded with ASCII. Namely, you use ASCII because you encode sequences of characters, and you use characters because you want the data to be perceptible by human eyes and brains. So the data is text or something close enough (e.g. XML). Some characters will be more common than others. Some patterns will be used.

The whole idea of a reused one-time pad is that it transports information from one plaintext to the other: if you know 'A xor P' and 'B xor P' (A and B being the plaintext bytes, P the pad), then you can compute 'A xor B' by xoring the two values together. Then every bit of information you learn about A yields the corresponding information on B. For instance, if A is some XML text and you have already ascertained that some plaintext bytes are "<config" then you can guess that the next byte of A will probably be a ">", a space, or a "u". These are three possible plaintext bytes, from which you can immediately deduce the only three possible plaintext bytes at the same position for B. Depending on what you know of B, you can prune out values which "make no sense", and thus know the byte value for A, and so on.

When breaking the infamous two-times pad, you just keep on propagating information from one plaintext to the other, and back.

ASCII already says quite a lot, because valid ASCII values are in the 0 to 127 range, but in "normal" text, a lot won't appear: in the 0 to 31 range, only 9 (tab), 10 (lf) and 13 (cr) will be encountered in practice.


Why is it a bad idea for management to have constant access to every employee's inbox? This was prompted by my CEO asking to get permanent access to everyone's inbox.

He wants for his email client to be configured so that as well as his own email account, he can see the contents/activity of everyone else's as well.

What are all the reasons why this is a bad idea from a security perspective?

Related corollary:

What are all the steps he would have to take to prevent anybody gaining access to/abusing his now god-mode account?

So many reasons:

Security Risk
Legal Liability
No Plausible Deniability
Not Scalable
Memory and System Requirements
Unnecessary and Redundant
Unproductive use of his time
There are better ways to monitor employees
Et cetera.

The biggest reason is the security risk. If someone stole his computer, or hacked into it, they would not only get his email, they would get all the email of the entire company, including any trade secrets and confidential information they may contain. Sure, all that information is on the mail server, but the mail server usually has much better security attached to it.

The second is that it is redundant. If he needs access to an employee's email, he can get access to it through IT. He doesn't need it popping up on his computer in real time as well.

And if he is looking at everything, he is focusing on nothing. There is no way he can keep up with emails everyone in the organization sends and received. If he has specific concerns about particular employees, then look at those email accounts. It's more focused and a more productive use of his time.

If he is concerned about certain types of emails, a system can be put into place that flags emails and employees that might need to be reviewed.

Another issue is memory usage. Is his computer actually going to be able to handle 100,000 to 1 million emails in Outlook (or whatever mail client he is using). Probably not.

Besides all of this, such an invasion of people's privacy could cause a hostile working environment, and harm productivity.

Then you have the legal liability. If the CEO gets a copy of every email, and he does not read all of them, and one of the employees does something bad that the CEO does not catch, the CEO could be accused of approving the conduct or casting a blind eye. Instead of the CEO having plausible deniability, prosecutors might accuse him in being complicit in a crime, simply because he did not read every single email the organization sends or receives.

And, this is not scalable either. The more employees he has, the less he will be able to review all the emails. The bigger the organization, the more likely he will be held accountable for an email he didn't have time to read.

There are much better ways to monitor employees than this.

For example, if he really needs that much control over what employees say and don't say, then create a compliance department that spot checks employees, or implement a ticket system which tracks all emails in and out of the system that can be logged into and spot checked from time to time.

Many systems work with email that give advanced functionality, such as:

ticket systems
project management systems
team collaboration systems
etc.

In fact, such a system, that he can log into anytime, might be a much better solution, and give him the access and sense of security he is looking for.

Setting up his computer to access everyone's email account is too risky.


TLS and reverse proxies Hypothetically speaking, let's say I purchase the domain eve-mail.com and get a cert via LetsEncrypt.  I then use a reverse proxy to point to the reputable and widely used alice-mail.com.

Connecting to eve-mail.com would present with a  but would allow for the sniffing of clear text data between the client and alice-mail.com.

What (if anything) prevents this from happening?

What you describe is basically a typical phishing attack, where the victim is lured into visiting your evil domain while the victim is assuming that it is visiting the correct domain. The victim is then expected to leave sensitive data which the attacker can grab.

The main difference to the usual credential phishing sites is that the attacker forwards the data between the victim and the original site, so that the victim gets the expected behavior from the site while the attacker gets the secret data of the victim. The idea is not new, see for example New Reverse Proxy Tool Can Bypass Two-Factor Authentication and Automate Phishing Attacks.

There are a some possible protections against this:

Look at the URL and make sure it is the expected one. But this is not as easy as it sounds since similar or look-alike URL's (similar names, punycode attacks, ...) are possible.
Use a password manager which fills in the password to the domain in the URL. This way the password will not automatically be entered into the website and the user will hopefully wonder why this is the case and look more closely at the URL.
Similar newer authentications like FIDO have authentication bound the the actually visited URL and will not be tricked by this either.
If the original site requires client certificates the attack will also not work, since in order to create a TLS connection to the original site the attacker would need not only the victims certificate but also the matching private key, which is kept in the victims browser and not transferred inside a TLS handshake.
The site itself might use some JavaScript to check which URL it is on and in doubt enforce the correct URL or block access. Sure, once the attacker knows that and how this is done he might try to replace the script and spoof the response.


Java desktop app vs web service I currently have a desktop app written in Java (Swing) which talks to a C-based backend over SSL. I am trying to understand the pros/con from a security perspective to move to a web service model. There are multiple business and engineering reasons to do it but our business data is very sensitive, so security trumps the other reasons.

I hear about Java security patches every other week it seems but hear similar things with web browser/server exploits. For the web services model we would plan to use node.js running in a docker to isolate it. It would be talking to redis and/or postgresql only.

I am going to answer your question with a barrage of other questions.

Well does your app actually need to hit the open internet ? or can it simply exist on a company intranet?

The majority of 'java exploits' are simply ways that java's sandbox can get broken out of and of little consequence to legitimate java applications since it is really a apples and oranges comparison.

The majority of 'browser exploits' are of a similar vein (gaining access to a system or other data in the browser, by breaking out of the browsers sandbox. ) Chrome helps a little bit in this though.

That being said the majority of 'web server' exploits are based around being able to execute your own code or extract data that you are not supposed to.

If you have a java app talking directly to a C back-end via sockets how locked down is your C app? The potential for damage can be quite high ( since depending on your software you have the potential for rop chain exploits or even direct code execution, as well as having your entire processes memory becoming available.)

This would require a more sophisticated attacker.

On the other hand if you have a COTS web-server then you run the risk of having a less skilled attacker be able to run around your systems.
And all re-writes are doomed to make the same mistakes that the original code made, (even if the original programmer is still around. )

I would personally stay away from node.js simply because it is such a immature technology compared to other options.

What is the potential cost of compromise?
What is the potential outcome for compromise?
Who would have a vested interest in compromise said system?
Is it data theft or data manipulation that will hurt the most?


Retrieving saved password from Firefox on Linux I know there are ways to get the cookies from browsers in Windows and retrieve and decrypt saved passwords from them. Is there a similar way to do so on CentOS?

Yes it's possible, even over ssh and quite trivial to do.  Enable X11 forwarding over ssh (e.g., -X option), start firefox, go to Preferences -> Security -> Saved Passwords -> Show Saved Passwords.

You could also find them in the relevant files in ~/.mozilla/firefox/{ user_profile } specifically key3.db for the encryption key and signons.sqlite for the encrpyted passwords.  (They aren't in plaintext.)


Utility of Output Chains in IPTABLES when there is no Network Firewall-- Is it ok to permit all outgoing connections from a server? I have a set of INPUT chain rules restricting traffic based on source ip and destination ports.The services are ftp and a job service.The server has a public ip address.

The default policy of the INPUT chain is deny. The default policy of the FORWARD chain is deny.

The only service accessible from any ip address is the ssh service(updated software).

There is only one user on the system, that is the admin user.

My question is, is there any utility in putting OUPUT chain rules on this machine.
And have any one of you come across attack cases where the attacker is able to initiate network connections from the machine without getting root access ? (if the attacker gets root access, then he can simply knock off the iptable rules)

It is a good idea to have secure egress rules for your server. This can protect against an attacker gaining a reverse shell.

  Remote shellcode is used when an attacker wants to target a vulnerable process running on another machine on a local network or intranet. If successfully executed, the shellcode can provide the attacker access to the target machine across the network. Remote shellcodes normally use standard TCP/IP socket connections to allow the attacker access to the shell on the target machine. Such shellcode can be categorised based on how this connection is set up: if the shellcode can establish this connection, it is called a "reverse shell" or a connect-back shellcode because the shellcode connects back to the attacker's machine

If there are any vulnerabilities on your server and you have secured the ingress rules to prevent the attacker running another service and then connecting to it, it is a good idea to prevent the attacker from connecting to other hosts from any sort of access gained from your machine. This will reduce the risk if you are running things with the rule of least privilege. That is, they may not have root but they could then do other things such as downloading tools and/or exploits from their own machine over the network or internet with a view to privilege escalation. Locking down outgoing connections can significantly reduce this risk.


How Involved Should a Developer Be in Designing a Security Policy? I've been developing software for well over 20 years. During that time I've worked in Fortune 100 companies that had very specific security requirements developed by dedicated security professionals and tiny companies with no concept of security requirements whatsoever.

It seems to me that very often, the majority of the time even, the de facto security policy ends up being created almost incidentally by programmers and tightly integrated into the finished product. Most businesses seem to just buy something and use whatever the default/hardcoded rules are without further consideration.

My question is, in a perfect world what should the role of an enterprise application developer be in determining security policy for their software? Should a product implement ironclad "best practice" or focus on being configurable and allow the consuming company/organization to determine their own policy?

(I'm talking here about things like if and when two-factor authentication is required, password complexity requirements and how long timeouts are and how many bad passwords can be entered before a lockout.)

EDIT:

OK, just to reiterate, I'm not talking about actual vulnerabilities like XSS or SQL injection, but policy. Suppose for an example that I didn't know how long a password needed to be in order to be sufficiently secure for my context and I'm only allowed a few hours to work on the minimum password length code. Am I better off researching how long is long enough and hard coding my decision or writing code that let's the admin customize it themselves?

I'm also a developer, and my passion for security often makes the dynamic a little unusual when dealing with other non-security-focused developers.

There are three main areas of constraint when it comes to security policy:

Usability: Making sure that the user can actually use the software, and that they don't get overly irritated or delayed by security measures.
Technical: Making sure than security mechanisms are properly implemented, and that they don't affect uptime, maintainability, or other critical technical factors.
Financial: Making sure that the security measures don't cost too much, whether it be through direct financial costs (e.g. buying black boxes with blinky lights) or additional man-hours.

Your job should involve advising on the technical factors, and suggesting ways that you might mitigate any usability impacts. However, you should almost always defer to the technical judgement of a competent security consultant (competent being the operative word) if they disagree with you on a technical security matter. It's your job to integrate the necessities into a product in an optimal fashion, whilst overcoming the difficult hurdles.

In terms of direct involvement in security policy for software development, it largely depends on:

Whether you have a dedicated security person or team.
What sector you work in (means you might need to deal with PII or HIPAA data)
Where you are in the organisation, and whether you're in a position to effect change.
How security-focused the company is.

The interesting part of this question comes when you consider that most software organisations don't have a dedicated security person, let alone department. Regardless of whether or not your company does, you have a duty to learn about the types of security issues and mechanisms that apply to your work. If your company doesn't have a "security guy", that responsibility is even greater. Part of your job is to implement working and reliable software, which includes security, but another part involves relaying technical information to management in a way that they can understand. You can't do that effectively unless you understand the issues at hand.

In short, there's no simple answer. You're required to make some security decisions and implement certain mechanisms as part of your job, because that's what a developer does. As for how far you go, it entirely depends on you as a person and the organisation you work in. In order to make reasonable judgements when no overriding directive is provided, you need to put in the work to understand the issues.


What are some good references discussing the pros and cons of a company Wi-Fi network for personal use? I am a software developer at a company that currently does not allow associates to use personal devices at work (ethernet and guest wi-fi alike). This makes it very hard to work on side projects (like school) during lunch, or other down times.

I'm a programmer and not an infrastructure/ IT security guy, so from my point of view I see it as a win in many areas such as morale. But I know there are security concerns (as well as old-school management styles where internet access is seen as a time sink).

I want it and would love to have a good argument as to why it is a good idea. However, in general I want to be more educated on the subject.

Are there blog posts/articles/books that discuss this issue and its pros/cons?

EDIT:
We can assume that a separate network can be created that protects the internal corporate network, so that personal devices won't pose a direct threat to company devices within the network.

You asked for resources:
Cisco
Zenprise
InfoWorld
TrendMicro
Let me know if you need more.  The basic answer is, we need to figure out how to protect data on someone's personal device.  BYOD (bring your own device) is an inevitability, we just have to figure out how to do it.


Convert CSR to self-signed x509 Certificate Is it possible to receive a certificate request (CSR) and convert it to a self-signed X509 Certificate without having access to the private key that signed the CSR? I want to do the following: receive CSR from a client and translate it directly to a self-signed X509 Certificate as if it was the client to self-sign it (it is redudant I know but it is for a project).
Basically I want to copy a CSR to a X509 certificate without signing the certificate. I would want to do this for example openssl or golang (for the purpose of this question openssl is enough).

Self-signed certificate means that the certificate is signed by itself. Since signing is done with the private key you need the private key which matches the public key in the certificate. This means that if you want to keep the public key from the CSR you also need the matching private key.


How do I diagram a network node with multiple layers of trust? If I'm communicating security and trust over a network, I might simply note trusted and untrusted nodes. For example, when making an HTTPS connection over some kind proxy node that I own and operate, I trust the protocol and the entire node:

But some connections are more nuanced. I can trust HTTPS to secure the content of my message and the identity of the destination, but activity logs depend on my relationship with the operator and owner of the node. I might operate the node but not own it. Or own it but not operate it. Or neither.

Failed attempt 1

Failed attempt 2

How can I diagram this? (A general notation for layered trust on a single node is welcome. In other words, not specific to HTTPS and proxying.)

You may want to look into EFF's diagram of comparison between Tor and HTTPS for some inspiration: https://www.eff.org/pages/tor-and-https

Note the actual diagram in the EFF site is interactive, which is neat but not strictly necessary as you can illustrate the same using multiple images as well.

The basic idea is that you need to identify each piece of information that has different security domains and label which domain are privy to which piece of information.


Is a password in keychain more secure than storing password in plaintext? Many email programs such as isync and msmtp provide the facility of specifying a command that once executed prints the user's password to stdout. For example on OSX we can store the password in a keychain and then call the following command:

security find-internet-password -w -a user@email.com -s imap.email.com  <keychain-file>

Now if we let the security file access this keychain entry without asking for permission (because it's pretty annoying otherwise) then we have basically given anyone permission to run this command and whoever runs this command will be able to read the password. So naively it seems that storing a password in a keychain is not all that sage in comparison to storing it in a plaintext file.

Am I missing something? Also I tried to set the permission of the $(which security) binary to 700 but then the email program cannot run the security program so juts changing the permission of the security binary is not feasible.

I don't have any internet passwords stored in my keychain, but running security find-generic-password -w, I get this prompt:

Similarly, the first time I use an ssh key, I have to re-enter a password before it becomes always-available.

In general, this is how password agents work: they aren't any better than having a plaintext file on-disk once you've loaded the agent up into memory and unlocked it, but they provide extra protection once they go out of memory, since the contents are stored on disk encrypted.  So are they perfect?  No, but they're definitely still better than not encrypting your secrets at all.


Any Books/Sites/Writeups on IRC bot Security? I've written a scriptable IRC Bot and I want to harden it against exploits. To that end I've already written it so that it ignores its own messages (so that, for example, even if it echoes back valid commands for itself it won't execute them) and restricted certain features to a list of "authorized nicknames" so that sensitive functions can't be invoked by just anyone. Also, the nature of the scripting language precludes any eval-like exploits.

With all that said, I can still think of numerous ways of exploiting my bot. Are there any writings on the subject of IRC Bot security? Even a short article from a more competent programmer than I on the topic would be useful, but Google is not cooperating.

Like any software you need to harden it to only allow the user what you intend to allow him. In your specific question it really relies on what language you have programmed your bot in, what types of commands you allow it and how it sanitizes the input from the user.

I am not familiar with any books directly targeting security of an IRC bot, however there should be many clear guidelines on how to program safely in the programming language of your choice.

It is also very relevant to read the RF1459 on how your bot should behave when communicating over IRC.

When you initially set up your IRC bot make sure that the core functionality is in place and working properly. This is the simple stuff like:

replying to ping with pong
join channels

Then you need to dissect these operations and make sure that they are inherently secure. Does your bot reply to a random PING from anyone? What if I supply a buffer overflow attack against your bot with a "PING AAAA x50000"? Does it try to store it in buffer and copy it to the PONG reply? Perhaps the only source allowed to make a PING to you should be the server your connected too.

When you later make the bot to accept commands from anyone you probably want to whitelist (positive security model) the commands you allow (join, kick, ban, ping, ??) and then sanitize properly the input to the bot.

The sanitation that needs to be done is very dependent on what your bot actually does. For instance:

It posts results to a web page (XSS filters)
It stores data in a database (SQL filteres)
It runs commands on OS or similar interface (command filters)

When you design such a bot you have to try think of every possible way someone will try to exploit it. You have to be very careful and paranoid when creating it.