Can my open Firefox Sync session be used to circumvent a Master Password? In short I'm wondering what's stopping someone with access to my computer account to exploit an open Firefox Sync session to view my synced passwords, even if a Master Password has been set.

On this page Mozilla says:

  Even though the Password Manager stores your usernames and passwords on your hard drive in an encrypted format, someone with access to your computer user profile can still see or use them. The Use a Master Password to protect stored logins and passwords article shows you how to prevent this and keep you protected in the event your computer is lost or stolen.

In other words, the Master Password is presented as a solution for protecting my passwords even if someone has access to my computer user profile. One example of giving others access to my computer user profile would be if I had a weak or no password for my Windows user account, and then lost the computer, if I understand correctly.

When I have Firefox Sync enabled and I'm logged in, but don't have a Master Password set, I can freely enable and disable syncing my passwords from Mozilla's servers. It's basically a checkbox that allows me to download my passwords whenever I want, and the passwords are immediately viewable as long as I am logged into my Windows user account.

The Sync and Master Password are presented as being fairly independent features, which leads me to my question: since the Master Password is local to my machine, aren't my passwords requested in the same way from Mozilla's servers as if the Master Password had not been set? If so, then how does the Master Password protect my synced passwords from people with access to my computer user profile if those people already have access to my Firefox Sync session?

Is the Sync session's credentials now protected with the Master Password as well? Sorry if the answer is obvious, it isn't immediately apparent to me from my day to day use of Firefox.

According to Firefox Help - Recovering important data from an old profile:
Your passwords are stored in a JSON file that has encrypted entries, the keys are within a sqlite database.

key4.db - This file stores your key database for your passwords.
logins.json - Saved passwords.

So if sync is active and working with a attacker, you are vulnerable to this, luckily the sync service requires a password.
https://support.mozilla.org/en-US/kb/using-master-password-sync

The so-called 'master password' does not protect your passwords, it just blocks someone from grabbing it remotely.


Why are my gpg public key on my machine and on the key server different? When I generated my PGP key using GnuPG, I had saved the public key as an ASCII version and uploaded that to the server. Now I can see the key on the keyserver but they are different blocks of data.

I have  a local copy of the above key obtained with gpg --export -a 33E0C879 > mypubkey.asc. The contents of mypubkey.asc and the content block on the server are different.

Is this by design? I am  new to PKI and very curious to know.

There are lots of reasons for this.

Keyservers can modify the order of your keys, signatures, ... occuring without changing the meaning of the data
Lots of keyservers ommit picture UIDs
The keyserver could know more signatures on your key than your local keyring does

You may not compare the contents of the (binary|ascii armored) version of your exported key by comparing them directly, only reimport them and compare the output of eg. gnupg. Remember sorting is irrelevant.


How to secure a price passed to a payment gateway on client? Using Javascript, say a customer buy a product that cost 10$.
Many payment gateways, like PayPal and Stripe, offer a client side Form where you input the sale data (price, amount, buyer address, etc), and it's being sent to the gateway (e.g PayPal) from the client side.
But, at this point when i fill the form using Javascript on the client side, someone can change the price from 10 to 1 and pay only 1 to PayPal.
I know things has to be validated on my server, but validation means that the server is sending back to client a response saying this price is good or not good, but this respond can also be manipulated.
So how is it that companies allow client side payment anyway using a form ?
How/where the actual sale data is being passed to the payment gateway ? client? server?

This is the reason that Paypal has the IPN.  One of the values sent in the IPN message from Paypal to your server is the transaction amount.  If the client were to manipulate the transaction amount the way that you described, you would be able to detect this in your IPN listener script, and cancel the order.  See https://developer.paypal.com/docs/api-basics/notifications/ipn/IPNImplementation/ for more info.


Why did I get a wrong IP and certificate for www.facebook.com just now? I just navigated to www.facebook.com and my browser alerted me that an invalid certificate has been received. I checked the cert in question, and I was surprised to see that the Common Name on it was www.hackermagnet.com.

After the initial freaking out, I started up Wireshark, reloaded facebook and checked the packets transmitted. I saw that the response to the DNS query for www.facebook.com was, in fact, the IP of this www.hackermagnet.com.

While I do have a notoriously bad router, I considered it could have cached the wrong address for facebook, but I don't think I've ever visited  hackermagnet for that to happen. Could this be a rare ISP mixup or something like that? Besides, even if I asked hackermagnet for its certificate, why would it respond when in the Server Name Indication extension header I can see that my browser asked for facebook's certificate specifically?

The issue fixed itself after a while but this whole thing worries (and baffles) me.

Thank you for your time.

My computer uses 192.168.2.1 (my router) as a DNS, while the router obtains DNS info automatically via the PPPoE interface. Currently the router's DNS servers are 62.38.1.81 and 62.38.0.81 (secondary).

Sounds like either your router or your ISP's DNS server was hit by a DNS cache poisoning attack. The following article describes how this might occur: http://www.networkworld.com/article/2277316/tech-primers/how-dns-cache-poisoning-works.html

Because this only is able to change the configuration for the Time To Live (TTL) of the domain being hijacked (facebook.com), it will go away of its own accord once that time has expired, unless the attacker is able to repeat the attack.

You may want to configure the systems on your network as well as your router itself to consult a (more or less) trusted public DNS server in place of those provided by your ISP. One example is Google Public DNS at 8.8.8.8 and 8.8.4.4.


Is my sending of encrypted information secure? Please bear with me as I am not an expert in security. I have a server and a client. On the server I am encrypting a very secret message (using AES256-GCM to hide the information and protect it's integrity) that I will send to the client. The client though will never decrypt this message, they will only receive it from the server and send it back to the server with their requests. My server will then decrypt and get the secret message which it needs to process other information. I need to ensure the client will never know of the contents inside the message. I am using javascript (NodeJS) for my server code and it looks like this (hopefully it is simple to read and easy to understand):

var crypto = require('crypto'); //get crypto library
var algorithm = 'aes-256-gcm'; // select which algorithm I want to use
var password = '3zTvzr3p67VC61jmV54rIYu1545x4TlY'; //Random generated 256bit key

function encrypt(text) {
  var iv = crypto.randomBytes(128) // generate a random 128bit iv for every encryption
  var cipher = crypto.createCipheriv(algorithm, password, iv)
  var encrypted = cipher.update(text, 'utf8', 'hex')
  encrypted += cipher.final('hex');
  var tag = cipher.getAuthTag();
  var enc = {
    content: encrypted,
    tag: tag.toString('hex')
  };

sendToClientOverInternet(enc,iv); //send the encrypted content + the iv to client over the internet

}

function decrypt(encrypted) {
  var decipher = crypto.createDecipheriv(algorithm, password, iv)
  decipher.setAuthTag(new Buffer(encrypted.tag, 'hex'));
  var dec = decipher.update(encrypted.content, 'hex', 'utf8')
  dec += decipher.final('utf8');
  return dec;
}

I am concerned more of the process and encryption methods opposed to infrastructure security. With that lets assume my server is completely safe and the hard coded password in my code will never be accessed and the transportation of data over the internet is over ssl.

My code with my questions:

1) First I generated a global securely random 32byte key.

Q: Is this the correct size? Any way to improve the key?

2) I have an encrypt method which takes some text and encrypts it using AES256-GCM. It then takes this encrypted object and along with the iv(128 bit securley random generated for every message) sends it to the client. The client if they wanted to then could now see this encrypted object and the iv.

Q: Is protecting the integrity of the data using GCM necessary? If I use CTR instead wouldn't it be impossible for the hacker to decrypt and change the message anyways without the key? So is GCM 'overkill'? Is sending the iv and having it accessible to the user safe? Is a 128 bit iv long enough? Any big improvements I can make here?.

3) I have a decrypt method which takes my encrypted string and decrypts it.

Q: (I don't think anything here needs to be improved).

Any improvements or suggestions would be greatly appreciated.

I assume the client and server communicate via some secure channel e.g. TLS? Otherwise anyone sitting on the wire can mount a replay attack i.e. intercept the ciphertext sent to the client, and send that ciphertext back to the server to impersonate the intended recipient.

From the comments it sounds like you are using the ciphertext passed to the client as a way of not maintaining state on the server. More specifically, you send a message to the client of their encrypted state and then have them send it back and decrypt / process that state on arrival. If you are already storing the encryption keys is it really that much harder to refactor to storing session tokens?

Regarding your question using GCM

The iv (or nonce as it's generally called in GCM mode) is sent along with the ciphertext, the security of GCM does not rely on the iv being secret, only that it is never reused, so 128 bits of random is fine (though as Xander's answer states, there are theoretical attacks against ivs that are not 96 bits). As long as your key has enough entropy you should be fine.
GCM does get around some of the problems other modes have. CTR (which you mentioned) and CBC for instance have bit-flipping attacks against them where the ciphertext can be modified without knowledge of the key to produce meaningful changes in the plaintext. CBC and CTR modes would require a MAC of the ciphertext sent along with them to verify the integrity of it. So while it is possible to use these modes securely it's requires a couple more steps than GCM.

In conclusion this construction is rather unorthodox, and a mechanism such as session tokens would improve performance (and give the benefit of being a tried and tested method). If you must go this route though GCM should be fine for keeping the data secure from the client.


Is Chromecast's UPnP requirement "a security nightmare"? I'd like to use Chromecast on our office network. Doing so requires enabling UPnP (Universal Plug and Play).

A quick search turns up statements like this:

  The US Department of Homeland Security is urging everyone to disable the common networking Universal Plug and Play (UPnP) protocol...UPnP has been, is now, and will always be a security nightmare of a protocol.

  http://www.zdnet.com/article/how-to-fix-the-upnp-security-holes/

I know very little about network protocols beneath the application layer, so much of this goes over my head.

Is it true that UPnP is fundamentally and irreversably flawed?

Are there any mitigating circumstances in which it isn't "a security nightmare"? Is there any way to use Chromecast without compromising security?

As long as you keep UPnP blocked at your gateway, you will be fine against any direct attacks against UPnP.  Later in that same article you linked:

  First, and foremost, you need to make sure you've blocked UPnP at your
  Internet gateway. Specifically, you need your firewall to block any
  system from outside your LAN from accessing the ports 1900/UDP, and if
  you have Windows systems, port 2869/TCP. Of course, what you should
  have been doing all along with your firewall is blocking every port
  except the ones, such as the Web's port 80/TCP, that you must use on a
  daily basis.

However, you will still be prone to lateral movement from an attacker gaining entry into the network from another attack vector.  Once latched into a network, typical reconnaissance involves scanning for vulnerable devices like those running UPnP.  The article does a good job to describe how vulnerable UPnP (or more likely, the various implementations thereof) are, so you will have to weigh the risk of running a vulnerable protocol behind your firewall.


Why is VirusTotal "unable to process file type" for files packed with Mpress? Packed an AutoHotkey script with ahk2exe using MPress, got 13 hits on the VirusTotal online scan for the zipped result. Packed the same script with the same ahk2exe without MPress and got just 6 hits on the zipped result. Zip performed with identical 7z defaults in both cases.

Some of the virus agents associated with red flags in the first scan now come up as "Unable to process file type" in the second report.
Why is this?

It’s likely the antivirus products are detecting the usage of MPress itself as a sign the file is malicious.

Executable packers create files which are usually significantly different from “normal” programs in a few ways:

the headers are minimised, the MPress site claims to remove standard features like debug directories and relocations.
executable sections have high entropy (due to compression) and usually minimal space between them (a normal PE has a lot of null bytes).
code sections often have read/write/execute permissions, or code is created in memory with write permissions and then executed. This allows code to be decompressed in place but is unusual (outside special cases like JIT compilers).

Other reasons antivirus programs may detect these files include:

they are often used by malware, and rarely used enough for vendors to worry about false positives (users can add exceptions).
there are few compelling reasons to use packers nowadays, as storage sizes and download speeds exceed requirements for most programs.

As for the reasons files can’t be scanned, this is vendor specific. Perhaps something about the ZIP file is unusual, and the engines are refusing to scan to avoid problems. If you supply hashes of your files it might be possible to compare them further.


Header opening a PDF file, can someone hack a website from there? Can someone hack a website that uses this kind of header to open a pdf?

<?php
header("Content-type:application/pdf");

// It will be called downloaded.pdf
header("Content-Disposition:attachment;filename='downloaded.pdf'");

// The PDF source is in original.pdf
readfile("original.pdf");
?>

There's no security vulnerability directly in your code.

As an aside, I assume you're using parameterized queries via MySQLi or PDO when doing database calls? If not, you're highly likely to be vulnerable to SQL injection in other parts of your site.


'Removing' telecom provider from my phone Baseband Processors have very weak overall security(closed-source firmware, no audits etc.)
It also gives the telecom operator very high privileges on a mobile device.
So, now I use 2 phones. First one being a 'relay' which has a SIM card, and connects to the internet normally. I turn this phone into a Wi-Fi hotspot and then connect the second phone to the Wi-Fi network of the first phone.
And this second phone is actually the personal device which I will use for open-source E2E encrypted communications, web-surfing and other normal mobile phone usage.
This second phone is not going to have a SIM card, have a custom ROM, and all other radio-communications(except for Wi-Fi) switched off always.
Will this method strip the telecom provider of the first phone(which was my main SIM card) off of any 'super-powers' they have on my phone(the second phone) through the baseband processor?
Note:

I know the risk of an unlocked bootloader, so please do not mention that.
I cannot trust my telecom provider at all.
I change the first phone's hotspot's SSID and Password every 24 hours.

Baseband processors (modem) are not vulnerable by design. They can be as secure as the operating system. Network operator doesn't have any special privileges over them unless your device is a carrier locked device whose firmware was installed by the carrier in factory.
OS updates for carrier locked device are delivered by carriers themselves. They don't have to compromise modem to remotely execute some code. If that device is connected to internet, that is enough for them to compromise it. Carrier locked devices may already have a vulnerability that is only known to the carrier.
If both of your devices are retail devices then there's nothing carrier can do to compromise either of them unless there's a critical vulnerability present either in the driver or in the firmware of the modem, that is known to the carrier.
Your setup is not providing any more security than using a single custom ROM device directly. If your network operator is a threat to you, you need to be wary of OS updates that were last rolled out for your device and known unpatched vulnerabilities in modem. Chipmakers do roll out patches for critical vulnerabilities in modem but old devices that are no longer supported by OEMs are left unattended.
In carrier locked devices, carriers also add further delay in delivering OS updates once OEMs deliver them to carriers. This is where the gap between security holes and security patches start rising.


Session Fixation cookie delivery I found a possibility for session fixation in an application I am researching. It is a session fixation through a session ID cookie. Now I've read up on session fixation and the concept is clear and comes down to getting a victim to use the cookie value you (attacker) provide.

From what I understand you cannot set a cookie value for a different domain than you are from. So you cannot just put on your evil site (evil.com) set cookie: sessID=1234 from targetsite.com. So my question is what are all the different avenues that can be used to deliver the cookie to the victim? I already listed the ones I found, so the question is, is there more? (I want to use this information mostly to create some awareness in management that it is a serious thing session fixation).

The ones that I already know:

XSS (stored and reflective, but you need a vulnerability in the site itself!)
Leave computer open with page open and wait for someone to login
MitM (but then you would be able to do a lot more than just fixate a session!)
Meta tag injection
DNS server hacking (which is a bit much I think for something like this, but comes down to getting into the domain of the target through the DNS server. As far as I understand it).

In addition to your list:

Uncontrolled subdomain

Your site runs on example.com although the attacker controls bob-usercontent.example.com. This could either be through poor design or a server admin has created a subdomain for a user unaware of the vulnerabilities this opens with cookies.

Attacker sets their website to output the header:

Set-Cookie: sessID=1234; Domain=example.com

and then entices their victim to visit bob-usercontent.example.com. This could be any resource, including an image embedded on another site.

When the user then goes to example.com and logs in, the cookie will log in the attacker.

Insecure subdomain

Similar to the above, but this time there is no design flaw.

static.example.com contains a DOM based XSS vulnerability (for example).

Attacker entices user to visit

http://static.example.com/page.html?name=<script>document.cookie = "sessID=1234; Domain=example.com";</script>

(Of course the name parameter would be percent-encoded, but left as is here for readability.)

When the user then goes to example.com and logs in, the cookie will log in the attacker.

Lack of HTTP Strict Transport Security policy

User visits arbitrary websites over HTTP.

Man-In-The-Middle attacker intercepts one of these requests and redirects it to http://example.com. Attacker also intercepts this request and responds with their own page that sets the following header:

Set-Cookie: sessID=1234

When user visits https://example.com, the cookie is already set and upon login the attacker is logged in. More on HSTS here.


How do connection relays strengthen anonymity? We've all heard of the concept of some geek bouncing their internet connection over a number of servers to hide their trail when doing something secretive. I'm curious about why this is done. I know the raw basics of TCP and SSL, but it isnt clear to me how tracing someone's internet connection even works.

Let's say I'd like to run a black market online

I place my web server in a shack purchased under a fake name in a country where it's hard for outside authorities to legally act/investigate.
I want to remotely connect to this web server to manage my market, but I'm worried about the NSA or CIA or FBI catching onto my market and tracing the server back to me, at my house in the USA.
So I could connect via an SSL encrypted connection, but if my packets are intercepted, the headers are going to still show the origin of my packets, even though they can't see the contents. That's enough to associate me with the illegal market run on the web server, and I'm in prison.

So, I need to encrypt not only the contents of my packets, but the headers too. This is where my knowledge ends. I'll note my current research on the subject to highlight where my confusion is:

If the authorities know about my server, and want to find who it is connecting to it, to nail their culprit, they'll need to intercept my packets between the server and an unknown location. Where do they hook into the network and how do they know which packets are originating at the server? I suppose they could cut the wire coming from the server's location, place a machine that reconnects the two ends, and sends data through but watches the contents, where they can read the origins of my remote connection via the TCP headers. But that seems extreme. Do they run to the nearest ISP data center and plug into the servers? Is that where they look into the traffic and pinpoint any packets coming to/from my server?
Tor manages to encrypt the headers so that's taken care of right? That can be done either via Tor or via my own software design.
But next, the common idea is that I would next route my packets through a bunch of different servers. Tor does it, or I could do it via my own set of proxy servers. Perhaps 300 personal computers that I've compromised around the world, I could reflect my packets from each of them as my remote commands are sent to the server and responded to by the server.

And so here is/are my question(s):

Why, if it's possible to encrypt my TCP headers, do I need to bounce my packets all over the place as if to give authorities the slip.
How do internet ISP servers know where to route my packets if their headers are encrypted?
And what is the result of me bouncing my packets somewhere else before they reach me? What do authorities now have to do to follow the route of my packets, exactly? And why does it matter if the TCP headers can be encrypted?

In other words: Why do connection relays strengthen anonymity?

There isn't any real magic here. The thought is that it is non-trivial to trace a message to it's physical location. It generally involves support by the ISP and is strongly regulated by the prevailing laws. So, while it is possible to trace messages, it requires some effort.

If I use an intermediate relay, the thought is that anyone tracing packets to my server will first find my intermediate relay. Upon analysis, they will see that it is acting as a relay and then they need to trace the relayed packets. So you've roughly doubled the amount of effort required.

If the relay and the server are in different countries with different laws, someone tracing the packets would now need to navigate two legal systems. And if the countries are known for not supporting this type of research, this could be very costly. Adding more relays increasingly raises the cost of tracing packets to the server.

Some negatives of this are increased communication costs, increased complexity, and having to deal keep up with changes in multiple legal systems.


Timing attacks in managed code I have heard that running code in a managed language, e.g. Java in the JVM, is impossible to protect against timing attacks due to the JITing nature of most managed runtimes. In concept I can agree with this, but I would like to understand what the current industry knowledge around this is.

A broad statement such as "this is impossible" is unlikely to be 100% accurate.

It is true that Java (and similar languages such as C#/.NET) runs with a JIT compiler that will produce the actual opcodes only at runtime, so the sequence of opcodes is harder to predict; it may also change with the VM implementation version. Moreover, the language has an efficient GC that promotes dynamic memory usage, and in particular immutable strings, which offer a lot of data-dependent timing behaviours.

It is still possible to write code that is immune to timing attacks, in particular for cryptographic algorithms. You just have to shun some of the nice properties of Java, and use it as if it was some kind of watered-down C. Work on arrays of byte or char, use arithmetic rather than tests... (so don't use boolean). For instance, this timing-immune code compares x and y, and swaps them if x is greater than y:

int cc = (y - x) >> 31;
int tmpx = (cc & x) | (~cc & y);
int tmpy = (~cc & x) | (cc & y);
x = tmpy;
y = tmpx;

We may note that Java makes such code actually somewhat easier to write than C since, contrary to C, it offers standard, fixed behaviour when right-shifting a negative value.


How to ensure that a person whose identity has been verified from an I.D. is the author of their exam answers? Background

We are designing a computer based test system where the examinees use their own computers to write their answers. The examinees' computers are booted to a custom Linux OS from USB drives provided by the examiner.

The USB drives that are used to boot the examinees' computers all contain exactly the same OS image.

The exam itself is provided by a central server and the answers are transferred back to the central server as they are being written. All the involved computers are in a closed LAN.

The system must support resuming the exam from the latest state transferred to the server in case of a hardware failure. The USB drive used as a permanent storage can potentially fail, as can the examinee's laptop computer.

The identities of the examinees are verified by trusted people at some point at the event (before, during, or after the examinees take the exam). The identity verification should cause minimal disruption for the examinees and minimal work for the trusted people. There can be up to a couple of hundred people taking the exam in the same space with approximately one trusted person per every 20 examinees.

Current design

Our current design is to generate a strong token on the examinee's computer when the examinee starts the exam. The token would be calculated using the SSN provided by the examinee, and some hardware UUIDs (CPU, USB drive). This token would be stored on the USB drive. When the examinee finishes the exam, she would pass the drive to a trusted person. The trusted person would then, using a dedicated computer, verify the identity of the examinee and the token stored on the drive against the token stored on the central server.

The pros of this design are that it is easy for a group of examinees to start the exam, and the verification is a read-only activity at the end of the exam. This design has at least one weakness: in case the hardware used for the tokens of two or more examinees breaks down simultaneously, it's no longer possible to verify who had hold of which device. For example, a power surge could cause multiple laptops and drives to break down at the same exact moment.

Question

What other attack vectors come to mind and how could they be mitigated? Any better alternative designs?

Attack vector:

Examinees may easily swap drives during or after the test, if there is no pre-authentication of which examinee gets assigned which token. Using just the token is not sufficient, as examinees may pre-arrange an SSN swap.

A gives B his SSN.
B startes the exam, generating a token for A's SSN on his usb stick.
After the exam is completed, B gives his USB stick to A.
A turns the USB stick over to the trusted person, who verifies that the token is correct for the supplied SSN.

Mitigation: USB sticks are collected by a trusted person (who also verifies identitiy on the spot and matches it to token on USB stick) prior to anyone being allowed to leave their desk. At no point can anyone leave their desks without supervision. Even in this configuration, it may be possible for students to have swapped sticks prior to ID confirmation.

IMO, a better configuration is not to store anything on physical media.

Instead, the test is served remotely in its entirety. In order to start the test, the examinee must supply not only his personal credentials (SSN, password, whatever your facility/institution uses) in combination with a random, pre-written key that the examinee is given access to only after (1) their identity has been verified, and (2) they can no longer interact with anyone unsupervised.


How to rate or review one Java web Application's security Is there a way to rate or review the security for a Java web application?
Except for web scanner or code audit, does it exist a metric/procedure to evaluate the application's security?

Also I have read How to rate Open Source Libraries? and Are there any web application security standards?, but they don't solve my question. I need a metric to rate the code, then can refactor the application's Java code in order to reduce its security weaknesses.

The CVSS rates the risk associated with vulnerabilities found in deployed software. Think of CVSS as a way to score the seriousness of traffic accidents. The Common Weaknesss Enumeration describes the software flaws and bugs that are the root cause of these vulnerabilities. Think of the CWE as analogous to the bad practices (gas tanks exposed to impacts, absence of guard rails, failure to buckle seatbelts) that cause or contribute to traffic risks.

The Common Weakness Scoring System (CWSS) is the scoring system for assessing software flaws and bugs. Given that weaknesses present different risks depending on temproal and environmental factors, DHS and MITRE have developed the Common Weakness Risk Analysis Framework (CWRAF) to give tool makers and enterprises greater flexibility in assessing the significance and priority of software issues and application security.

Other scoring systems include Software Fault Patterns from KDM Analytics and Semantic Templates  from Dr. Robin Ghandi and Dr. Yan Wu at University of Nebraska at Omaha and Bolling Green State University respectively.


In-Memory Database Storage and Security (MemSQL, Spark, Redis, Geode, et al) There is a growing trend to utilize more In-Memory Storage for a wide variety of use cases from big data analytics (Spark) to faster processing power (MemSQL) to caching (Redis) most frequently accessed data before making a trip to disk based RDBMS. AWS Elasticache is an example this. One architectural 'Best Practice' I've heard recently is to cache everything first. Then make trips to disk only for less used (cold) data.

With this growing trend to leverage more in-memory storage, I've not seen very much written about securing these data stores along with potential associated vulnerabilities that come along with them. When I asked Amazon if there is encryption available for Elasticache data they said no.

In addition, I'm not sure if traditional data storage security guidelines apply in the same manner as disk based storage for regulated agencies. For example, encrypting data at rest (DAR) is a NIST requirement for sensitive data (e.g. PII, PHI) in the cloud. Does this same standard apply to data which only exists in-memory? If not, is that really a good idea? Have NIST and other security organizations even considered the potential attack vectors in this space yet? If so, are there any published guidelines out there for in-memory storage? Or are we supposed to infer from old rules/regulations/guidelines and then extrapolate into this storage environment?

Any thoughts on Securing In-Memory Data Stores appreciated, especially from those who've had to certify the security of their systems through third-party assessors.

Encrypting in-memory data stores/caches is generally not done because all the working data is stored in RAM and so will the encryption key at some point and if an attacker has access to the memory of the system, he will have access to the means to decrypt the data or have means to access the data after decryption so it is not providing any additional security.

The best practice is to prevent unauthorized access from an external process or machine by making sure you have Threat Modeling done for your application. This will bring to light all the ways an attacker can get access to your data or attack it. There are several methodologies for Threat Modeling and the one I have used is STRIDE. There is a free tool which Microsoft provides which is useful to create Threat Models using this methodology. This is not specific to in-memory databases but more holistic as it covers aspects of security for a given application.


Are "web bugs" a technique that instructs web browsers to operate the computer's microphone? "Web bugs" [pg 7] refers to Javascript techniques that instruct web browsers to operate the computer’s microphone and locally search the audio for keywords. Would this be false? If so, why?

With the added context to the 2011 Berkeley exam answer sheet passed in your comments section the answer is indeed false.  They were looking for the Wikipedia definition of "Web Bug". http://en.wikipedia.org/wiki/Web_bug


How do Pentesters approach attacking 2FA (two factor authentication)? I'm looking for practical ways to attack 2FA. What do you need to consider and how would you go about testing the effectiveness of 2FA? My only thoughts are that you would attack the implementation itself.

Your goal as a pentester is to identify previously unknown or unrecognized threats.

Be extremely clear that anything you do here must be explicitly authorized by your client.  Failing to do so can get you in serious trouble.  If you are wondering about details on that ask in the Law Stack Exchange.

Attacking two factor can be easy if it is misconfigured.  In many cases there are reset or bypass mechanisms that fall back to email.  If it is properly configured it becomes impractical to attack directly and you need to look at avenues of capturing tokens or compromising an authenticated application directly.

If the second factor is a hardware token, you will need to MitM the application that is consuming the token.  If the application is HTTP or another unencrypted transport this can be achieved with network capture (not really MitM but you need a MitM position to do the capture).  If the application is using TLS with an invalid cert you can achieve this via DNS poisoning (waiting for DNS requests for the target domain and sending several DNS replies with large TTLs directing the user to your MitM with its own self-signed cert.  If the application is using HTTPS with valid certificates you could compromise an endpoint via other techniques and capture token entry on the user agent directly.  It may be worth compromising an application that consumes the token.  If they are using a TOTP token system you can compromise the weakest of the services using the same token serial and then reuse the token within the expiry window.  If they are using a managed one time token system like Safenet Cryptocard this will not work since the token is consumed on use regardless of timeout.  The trick there would be to capture the token on the first attempt, substitute a fake value to the real authenticator, and side-channel a separate session to authenticate.  That way the user will think they've mistyped and just re-attempt.  While you are in that position you may be able to directly hijack the session cookies or other tokens directly if complementary defenses like device/IP locked sessions or anti-CSRF are not employed.

If the second factor is already done over email then your attack vector is network capture of inbound SMTP at the MX.  This may not be practical if the customer is using a secure outsourced provider.  It should be relatively easy if they run their own mail servers.

If the second factor is done over SMS it may be possible to shoulder-surf tokens of you are physically present since many phones are autonaticLly configured to show texts even when locked.  There are more sophisticated attacks involving compromising phones that can be used otherwise.

Social engineering is the ultimate hack here though.  If you can somehow get a user to call you for help by posing as IT Support or otherwise they may just tell you the token directly as you "help" them fix their issue.


Storing only BIN part of PAN, does this qualify as a full PAN? We are looking at becoming PCI-DSS complaint. We wish to minimize the impact it will have on us and our business. As this can be a very expensive exercise. As I understand it if you do not store cardholder data that decrease risk.

My question is if we store only the BIN part of the PAN does this qualify as cardholder data? We wish to store the BIN in combination with the Cardholder Name.

Any clarification would be greatly appreciated.

Storing only the BIN part of the PAN does not qualify as a full PAN. When you are thinking about PAN storage, you have to consider Requirement 3: Protect Stored carholder data. Your question is answered by requirement 3.4 (this is an extract of the navigating PCI-DSS document):

  3.4 Render PAN unreadable anywhere it is stored (including on
  portable digital media, backup media, and in logs) by using any of
  the following approaches: One-way hashes based on strong cryptography (hash must
  be of the entire PAN), Truncation (hashing cannot be used to replace the truncated
  segment of PAN), Index tokens and pads (pads must be securely stored), Strong cryptography with associated key-management processes and procedures

What you are trying to do is referred as "Truncation", limited to the first six digits:

  The intent of truncation is that only a portion (not to exceed the first six and last
  four digits) of the PAN is stored.


In-memory encrypted Linux/unix kernel Is there a variant of Linux kernel for virtualization that runs in-memory in a state that can't be read by the host operating system?

Not possible. The host can read everything, no matter what it is.

Encrypted memory means there must be a decryption key, and that key must reside in clear, in the memory. The memory the host has full access. Not only access to memory, but the instruction execution too. No matter how you hide that, the host will have access.


Benefits of only allowing one password reset per day? I recently had to reset my password for a popular instant messaging service. Unfortunately, I failed to write down the new password I picked. So I had to reset the password again. That is when I got the following message:

Please wait one day before requesting another password reset.

A bit irritating, but perhaps motivated? What are the security benefits of this limitation? What sort of attack does it protect against?

Only the owner of this service can tell what is their motivation.
One of motivations may be following. Some systems track the most recent passwords and don't allow the most recent passwords be reused very soon. For instance if user wants to reset password and reuse one of the 10 recent passwords, system would not allow this.
Some users would reset password 10 times within short time, let say within 5 minutes, their "favorite" password will not be in the list of the most recent 10 passwords, thus the system will allow to use that password again.
Thus, if the system policy forces users to regularly change their passwords, e.g. every 90 days, effectively some users can ignore this policy by multiple password resetting and eventually setting password back to their preferred value.
If users are allowed to reset password once a day only (or other relatively small number of times per day), they will not be able to reuse their preferred password very soon and will have to wait relatively long, e.g. 10 days, until the system "forgets" their preferred password and they can reuse it again. This can discourage many users from using this trick.


What is a reasonable approach for deidentifying data? I have been asked by a client to deidentify the PHI data in their database and I'm either over-simplifying the process or my client is overly paranoid.  Perhaps you can tell me which is the case.

This client's need for de-identification is two-fold.  When they lose a client they have the right to keep a deidentified copy of the data for analytical purposes.  Also, they need to be able to move the data to dev/test environments in a deidentified form.

Here's an example of what would be in the database:
First Name
Last Name
Gender
Birthdate
Facility
Admission Date
Discharge Date
Admission Score
Discharge Score

This data is used for analysis and some of the important factors are:
Gender
Age at admission  (Admission Date - Birthdate)
Length of stay (Discharge Date - Admission Date)
Improvement (Discharge Score - Admission Score)

Here are my questions...

If I simply randomize the names, is this not deidentified enough to satisfy HIPAA requirements?

I didn't think so.  What if I also randomize the Facility name?  If I only know the other pieces of information, birthdate, gender, dates, and scores, has this been reasonably deidentified?

Ok, assuming the answer is no, what if I then choose a random birthdate and adjust the admission and discharge dates so that age at admission and length of stay are still the same?  For example, if the patient was born on 1/1/1930 and was admitted on 1/1/2011 and discharged on 1/10/2011 the birthdate could be randomly chosen as 5/5/1920 and the other dates would be 5/5/2001 and 5/14/2001.  The age at admission and length of stay would be the same.  Would this be reasonably deidentified?

Also, one other question.  If the client has a list of patients with their birthdates in an excel spreadsheet (no other information), would that data be considered PHI?  My client says yes, but that doesn't make sense because no medical information is tied to those names.

Thanks for your input!

Darvis

I genuinely don't think we have enough information - and it sounds like you don't either - on what exactly your client wants. Part of your problem is not just deidentification, but deidentification that maintains the data's usefulness. The second part is as tricky as the first.

  Ok, assuming the answer is no, what if I then choose a random birthdate and adjust the admission and discharge dates so that age at admission and length of stay are still the same? For example, if the patient was born on 1/1/1930 and was admitted on 1/1/2011 and discharged on 1/10/2011 the birthdate could be randomly chosen as 5/5/1920 and the other dates would be 5/5/2001 and 5/14/2001. The age at admission and length of stay would be the same. Would this be reasonably deidentified?

For example, this solution, while it might technically have changed the PHI so it cannot be tracked back to a particular individual, has ruined any and all time related usefulness of the data that isn't just the difference between the admission and discharge date. An analysis of the data could not, for example, adjust for what season of the year the admission was in (important for many diseases) or even what year the admission was in (important for all kinds of things).

  Also, one other question. If the client has a list of patients with their birthdates in an excel spreadsheet (no other information), would that data be considered PHI? My client says yes, but that doesn't make sense because no medical information is tied to those names.

We don't know who your client is, but considering the site you're asking this on, the answer is absolutely yes. The existence of these records implies certain medical information. Consider three circumstances, of varying risk to the patient if exposed:

Patent X is on Clinic Y's list. They must have gone there.
Patient X is on Clinic Y's list. That clinic does STI screening. I wonder what they were up to?
Patient X is on Clinic Y's list. That clinic is helping administer an HIV prevalence study among high-risk sex workers in the area. Isn't that interesting...

All of those could be assembled with nothing more than a name and birthdate, and the existence of the list itself. "Shows up on in a healthcare provider's records" is medical information.


What are the webmalware effects on Windows XP? I am redirecting URLs to a virtual machine (Windows  operating system) to check if there is malware on the website i want to visit (JavaScript attacks, drive-by download attacks, infected pictures/PDF files or executables embedded on the webpages ...).
In the case there is a webmalware embedded on one of the webpages: what aspects of the virtual machine must I check for eventual changes done by the webmlware ?

Nothing should be changed except the downloaded Internet files.

I would take a snapshot of the fresh VM and revert back every night (or sooner if it detects evidence of malware). That way, it is free to be compromised, but you limit its effect.

Unless you hope to inspect changes in the VM as the method of detection that there has been malware, in which case you simply look for ANY changes outside of the downloaded Internet files.

It looks like you are trying to combine a proxy with a sandbox? Sandboxes are best used in parallel and not in-line for safety sake.


Does TLS-OBC only improve security of Web Browsers? Does it improve the security of SSH? I'm studying the TLS-OBC extension and would like to know if it improves security of non Web-based protocols?

Specifically, would it be of any benefit to SSH clients? (version 1 or version 2.x/secsh)

I'm just trying to understand the scope of applicability of this technology

SSH does not rely on SSL/TLS (see RFC 4253). OpenSSH relies on the OpenSSL library, but that's just because it reuses some of the cryptographic functions, which are common to the two protocols (OpenSSL does far more than SSL/TLS).

Therefore, you wouldn't be able to use TLS-OBS as such with SSH.

Would you want to generate a new key-pair every time you log on to a new SSH server, in a similar way to what's suggested in TLS-OBS? Possibly, but you wouldn't necessarily need a new extension to achieve the same goal. You might as well use the current methods: generate an SSH key-pair and add the public key to the authorized keys in your account the first time you log on.


SSH host key: Is the public one necessary and should the key be password protected I was playing around with my SSH server side config sshd_config. I replaced my default SSH host keys with only one RSA key while I'm using Protocol 2 and key auth only.

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa

This creates as expected two files

ssh_host_rsa_key
ssh_host_rsa_key.pub

While testing I found out it's not necessary to have the public key to establish a connection from the client.

When does the public key is necessary?
Furtheron I couldn't determine why it's necessary to have the private key password protected.

Q2. sshd host keys should not be password protected. If they are, sshd can't read them (unless you set up a host agent and preload it which is rare). This is because sshd is designed to run in background and cannot get the password(s) from the user, especially because it is usually started automatically at boot before any user is even logged-in. Instead the files for the sshd host key(s) should be secured against access by any userid other than the one which runs sshd, normally root, and that userid should be well protected and not used unnecessarily.

Q1. sshd does not need a separate .pub file because it can automatically compute the publickey from the privatekey. In contrast the client ssh (unless using an agent) usually wants to use the publickey for a userauth 'probe' before prompting for the password to actually use the privatekey, and this requires a separate .pub file except when using OpenSSH's 'new format' keyfile, which is required for Ed25519 since IIRC 6.5, and the default for all keys since 7.8 about a month ago. Since ssh-keygen doesn't know which you want, it always generates a .pub file, which does no harm if unneeded -- even if it is not secured, since it is public.


Numbers displayed in random order for password I see various sites using this kind of security(?):

Maybe it's only specific to my country (France): I never saw this elsewhere. I have to click on 6 number (the password generated by this kind of services are only 6 numbers, it was sent in an email and I can't change it) and the ordering of these numbers changes on every refresh.

What is the purpose of this kind of security? Is it secure in any way? I mean is it more secure than a classic 16 alphanumeric password without this bunch of button and JS code?

"Mot de passe" = "password"

P.S.: I can edit my question if something is unclear, maybe I forgot some context.

Officially, that is an attempt to foil keyloggers. In practice, it is just a way to give the user a sense of security by making them jump through hooks: it doesn't provide any practical improvement to the system's security.

Edit: Just to clarify: providing the user with a sense of security is a very valid design goal as long as the designer know this and implement real security behind the scene. For instance, if there is a really secure login scheme implemented but the user never sees it (because it is completely transparent to them) then implementing such security theater tricks will make plenty of economic sense (but it does not improve security).


Ability to determine which PGP public keys a message has been encrypted for? Is it possible to determine, given a PGP message that you can already decrypt, to determine which other PGP keys that message has also been encrypted for?

First of all, although you used pgp, I assume you will actually be using  GnuPG. Otherwise, fetch it - it's free software. Although PGP will probably also have similar functionality.

Hidden Recipients

It depends. If the sender included the recipient's key fingerprints, you can retrieve them; otherwise (if encrypted using the --hidden-recipient option) GnuPG has to test all your private decryption keys against the message.

Listing (non-Hidden) Recipients

If the recipients are included, GnuPG will list them when set to verbose mode (--verbose). To prevent GnuPG from actually decrypting the message, add --list-only. The relevant lines are the ones starting with gpg: public key is.

This will output public subkeys, which you have to resolve again using gpg --list-keys [key-id].

A complete command line to retrieve the recipients from a message:

cat message.pgp | LANG=C gpg --verbose --list-only 2>&1 | grep 'gpg: public key is'

If you even want to automatically resolve subkeys, additionally pipe through cut and xargs:

cat message.pgp | LANG=C gpg --verbose --list-only 2>&1 | grep 'gpg: public key is' | cut -d' ' -f 5 | xargs gpg --list-keys

LANG=C is used to enforce English localization, so grepping will not fail for other languages.


Keyboards immune to signal monitoring? Reading a couple questions and answers here recently got me to thinking.

Wireless keyboards run the inherent risk of exposing their data due to the relatively broad transmission range, and the ease with which highly sensitive receivers (remember, making an RF signal audible is more the job of the receiver than the sender) can be built.

Recent studies have also shown that even wired keyboards can be exploited via the RF emanated along their cable.

Even beyond RF sniffing, there's always the risk that some "cleaning lady" might throw on a hardware keylogger between the keyboard cable and the PC.

Are there any keyboards that are secured (via encryption, shielding, and/or other means) against monitoring via electronic signal leakage or interception?

EDIT:  I suppose I should be clear, in that I'm only looking to see if there are keyboards designed to prevent interception or monitoring of their electronic signals.  Please do not address any other attack vectors in answering this question, except perhaps as a sidenote.  I am aware that these attacks still exist, but the measures available to defend against them are beyond the scope of this query.

I wouldn't be surprised if there is hardware out there that can solve the problems you listed, but I would hazard a guess that they are very domain/environment-specific.

Then again, when you think about each problem seperately...

RF interception: The solution is proper shielding (and grounding of the shield)
Keylogger: Encryption isn't going to solve this problem.  A keyboard that can't be unplugged indetectably, nor taken apart could work.
Camera watching over head: SCIF room, or varient thereof.  http://en.wikipedia.org/wiki/Sensitive_Compartmented_Information_Facility

Actually, that last one solves all (most?) of the problems.

Seperating each problem into seperate solutions in this case (IMO) is sort of like remedying the symptoms of a disease, instead of the disease itself.

EDIT: While the question was intended to be very specifc in nature with regard to devices on the market, I don't really know if an answer can be given without adding proper context.


is it possible to upload infected pictures to a website? I have a  small website on which users can upload several types of files: images, zip files ... (except .exe files). Suppose a user uploads via the front end interface of my website a picture which is infected: will this picture be hosted without a problem on mywebsite or are they antiviruses/scanners hosted on the server on which i host mywebsite that check this ?

If your upload form are not secured and not verified lots of things about the files wich is trying to be uploaded on your server , yes you can upload an infected image.
You intercept the http header like tamper data or other tools , and you can modify the extension of your file and other parameters :
 example : http://exploiterz.blogspot.fr/2013/07/how-to-upload-sh3ll-using-firefox-adon.html

For the AV scan that's depends on the shell that you upload i think.

I hope this helps you , sorry my english is not very well.


Xubuntu guest session security lately I've been using the guest session on my xubuntu install because I am lazy and I was wondering what the security implications can be on the rest of the system if there is a web browser exploit or similar attack. Apparently it wipes the entire guest session every time you log out or it goes idle. Would a better alternative be just a regular user account?

Let's get into the details of what a guest session is on Ubuntu. You've asked 'is it more secure for the system to use a guest session rather a normal account?', and the answer is yes, but only slightly.

Guest sessions use a tmpfs instead of a home, so data does not get written to disk but stays in RAM. This means a prolongated session with important amounts of changes might cause your system to need swapping.

As far as I understand a user is created and deleted every time, albeit I haven't found the corresponding code in LightDM and the guest-sessions tree on Launchpad.

Processes in the session can only create TCP and UDP connections, although I'm not sure what the expected security benefits are (apart from preventing PPTP tunnels?).

AppArmor is used to ensure that this session cannot possibly write to the system, except for its own home and /tmp. This should normally cover cases when a root privilege escalation occurs within the guest session, but not attacks against the kernel itself. A regular account would not provide you with this kind of protection.

https://wiki.ubuntu.com/DesktopTeam/Specs/Intrepid/GuestAccount


Is there a way to modify the value of a session token with HttpOnly flag set in this scenario? SCENARIO:
When a user browses to the login page the web application sets SESSIONID=X; Httponly; before the authentication.
After the authentication NO new cookies are set. The only cookie used to identify the session is SESSIONID=X.
This should mean that the webapp is vulnerable to the session fixation attack.
I want to develop a complete attack so I need a way to programmatically modify the value of SESSIONID.
The server doesn't use security headers (X-XSS-Protection, etc.), so the login page can be inserted into an iframe and XSS are not blocked.
Is there a way to change the value of SESSIONID when the victim access the login page through attacker web server?

Is there a way to change the value of SESSIONID when the victim access
the login page through attacker web server?

Nope. When the victim visits attacker's web server and loads the iframe, victim's browser directly establishes new connection (such as HTTP request) to the website inside the iframe, not by going through attacker's website first then the real website.


Begin of Certificate/ End of Certificate dash "-----" What significance does the dash "-" holds along with the line -----BEGIN CERTIFICATE----- or -----END CERTIFICATE-----.

I checked multiple docs and linked RFC's as well but could not find the significance, one thing I got it "The number of dashs ("-----") is meaningful, and must be correct."

This is defined in IETF RFC4945, section 6.1 (page 36).

It is basically a standardised format for protecting important identifying start and ending sequences of encoded data in plain-text files, known as an encapsulation boundary, that has been around for a long time (since at least RFC934, published in 1984).


Is personal email hosting really secure? One of my friends has his own personal email hosting. Let's assume for the sake of argument that it is "secure", meaning that no third party can read the emails in his server either through hacking or a backdoor.

Does this mean that a government email surveillance system really cannot read his emails? Indeed, so long as his email conversations are with correspondents whose email hosting services are compromised, it may be possible to retrace all his emails from the compromised correspondents.

Is a personal (and secure) personal email hosting system really a protection against government snooping?

Nope it will be as secure as you can configure it and like you say the end point might not be secure. If you want to have security you should encrypt your emails with pgp/gpg.


Fuzzer causes crash. Now what? Can anyone point me in the direction of some good tutorials regarding how to identify the type of vulnerability as reported by !exploitable and where to go from there?

Essentially I've got myself a small fuzzing lab setup and I'm trying to broaden my understanding of exploit research and development. So I've got an app that crashes, !exploitable reports as EXPLOITABLE and a Write Access Violation. My issue at this point is I'm not sure what kind of problem is happening, and how to proceed.

Lots of exploit tutorials out there, except they all demonstrate buffer overflows....I'm not sure this is a buffer overflow. Opening the fuzzed file that causes the crash in Immunity Debugger causes the same crash at the same memory address as the !exploitable report. I compared the clean file to the fuzzed file in a bindiffer application and can see the exact hexdecimal change that is causing the crash, but I could use some advice on how to proceed from here in order to start putting together exploit code. I've attached the !exploitable read out in the event someone can provide me some more insight on it and how to gather meaningful information from it.

(834.b7c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=7fffffff ebx=00726afc ecx=0000c9f0 edx=02adc080 esi=02957b18 edi=00000000
eip=005ec57f esp=0187f810 ebp=0187f978 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010216
*** WARNING: Unable to verify timestamp for image00400000
*** ERROR: Module load completed but symbols could not be loaded for image00400000
image00400000+0x1ec57f:
005ec57f c704ca00000000  mov     dword ptr [edx+ecx*8],0 ds:0023:02b41000=????????
0:000> r;!exploitable -v;q
eax=7fffffff ebx=00726afc ecx=0000c9f0 edx=02adc080 esi=02957b18 edi=00000000
eip=005ec57f esp=0187f810 ebp=0187f978 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010216
image00400000+0x1ec57f:
005ec57f c704ca00000000  mov     dword ptr [edx+ecx*8],0 ds:0023:02b41000=????????
HostMachine\HostUser
Executing Processor Architecture is x86
Debuggee is in User Mode
Debuggee is a live user mode debugging session on the local machine
Event Type: Exception
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll -
Exception Faulting Address: 0x2b41000
First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005)
Exception Sub-Type: Write Access Violation

Exception Hash (Major/Minor): 0x00020e6f.0x435e5a76

Stack Trace:
image00400000+0x1ec57f
image00400000+0x1ebe05
image00400000+0x1eb966
image00400000+0x1eb7f3
image00400000+0x64405
image00400000+0x63eae
image00400000+0x63d2f
image00400000+0x41ca5
image00400000+0x39022
image00400000+0x5d9fa
image00400000+0x5e63f
image00400000+0x38862
image00400000+0x3032
image00400000+0x11d91
Instruction Address: 0x00000000005ec57f

Description: User Mode Write AV
Short Description: WriteAV
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - User Mode Write AV starting at
image00400000+0x00000000001ec57f (Hash=0x00020e6f.0x435e5a76)

User mode write access violations that are not near NULL are exploitable.
quit:

Corelan has a couple of good articles on taking a fuzzing crash through to exploitation :

https://www.corelan.be/index.php/2013/02/26/root-cause-analysis-memory-corruption-vulnerabilities/
and
https://www.corelan.be/index.php/2013/07/02/root-cause-analysis-integer-overflows/

Their methodology appears to be a case of looking at the original seed file that was used to generate the fuzzed message and slowly change it into the fuzzed message to identify which change(s) causes the crash.

Having done, that it is then a case of determining what the application does that causes it to crash by running it with an attached debugger and watching where your change influences the programs behaviour.  With that you are then looking to see what registers you can take hold of (Ultimately trying to overwrite EIP).   Or if it's a heap based crash, can you take overwrite some function pointers so that you could point them to your payload.


Beyond patching, how can I reduce the risk of browser exploits? Keeping web browsers on the most up to date version and also the plugins that are used is pretty much all we do.

Is there anything I else I can do to reduce the risk of browser exploits? The only thing I can think of that would help is least priviledge user accounts but that's quite a general good practice.

Given that a lot of browser base malware is delivered via ad networks, a decent way to reduce risks would be to use an ad blocker (e.g. Ad Block Plus).

Also something like Ghostery can disable a lot of, likely superfluous, 3rd party content on sites you're browsing, which again could host malware.  Realistically any content you don't visit is content that can't give return malicious content.

Additionally things like reputation filters can be useful, either those built into the browser, or one's from 3rd party security software providers.


What are the threats addressed by a Hardware Root-of-Trust? SoC's have begun integrating a hardware Root-of-Trust to mitigate attacks on Secure Boot. Examples include Google's OpenTitan & Intel PFR. What are the threats addressed by discrete "Secure Enclave" type root-of-trust solutions? What are the benefits over Secure Boot from ROM?

TL;DR: It lets manufacturers implement Secure Boot in a system where only the stuff that absolutely needs to be read-only is non-patchable, and protects them from their own mistakes when attempting to implement the basis of the root of trust themselves by having experts create and review the silicon in a transparent way.

The core concept of any Secure Boot system is that the system can only be started if the firmware verifies that the next step in the system (typically a bootloader) is trusted (typically, this means "signed using a specific key, or a key issued by a trusted authority"). Each subsequent step then verifies the one that comes after it. However, this presents a complication: where do you store the firmware? If you put it in writable flash memory, an attacker can overwrite the firmware with one that does not verify the rest of the chain, and bypass secure boot entirely. If you store it in read-only memory, then there's no way to update the firmware without tearing apart the hardware, and firmware can have bugs or need changes same as any other computer system.
The stuff you linked is an attempt to create a standard way to store a public key and a module which verifies that the device's firmware is signed by the holder of the corresponding private key (or by a key chaining to it), and which mediates access to that firmware. This allows you to create a device-agnostic chip (or chip module) that supports the fundamental baseline requirement of Secure Boot with the absolute minimum required functionality. This provides a minimal attack surface against the part of the system that can't be updated, reducing the risk of it containing a vulnerability.
It also means manufacturers, developers, and users can see what the root of trust is doing and how it works. Secure Boot has a major problem that gets at the very basis of what "security" means: preventing unauthorized access or operation. But, authorized by whom? For some systems like PCs, it's the owner; if I want to use Secure Boot on my laptop, I can control what signing keys are permitted. For others (phones, consoles, etc.) the manufacturer asserts that the owner does not actually get to decide what constitutes authorized use, and thus historically has tried to make the whole root of trust as opaque and user-inaccessible as possible, and limited outside review. Sometimes this backfires horribly, as with the PS3 and "fail0verflow", where Sony's poorly-implemented trust root relied on security through obscurity and was easily broken once people figured out how it worked. If a system like the ones above had been available back then, Sony and other companies could have had a system developed and reviewed by people who actually know what they were doing. The resulting product would both have been more secure (for the company, in that case, rather than for the users) and more updatable to fix the various other firmware bugs.


How can a DoS attack be used as part of the 'Gaining Access' phase of a hack? I'm doing some revision for an exam and I've made a note to look at how DoS attacks can be used to gain access to a system. I can't find anything online but I found a reference to the fact here.

I hope one of you can enlighten me

DoS attacks can be used in several ways as part of gaining access:

Overwhelming primary defenses. when you are conducting a DoS attack, the primary defense mechanisms get caught up in it too. They can be overwhelmed and as a result, they may: a) not respond appropriate b) can hang altogether c) the watchers watching them are distracted, or your efforts are lost in the DoS logs. In addition, if the primary systems are rolled over to secondary systems (which often happens) those may not be up-to-date configurations, or you could catch the roll-over in a time-gap whereby the synchronization of everything is not current.
Overwhelming primary systems may expose flaws. A DoS attack may be used to expose flaws that could be exploited. Could be procedural flaws, it could be system flaws. It could be that as a result of a DoS attack you force the organization to upgrade, and during the upgrade you take that window of opportunity to exploit.
The DoS attack is a decoy. Classic attack... What magicians do all the time. Watch the left hand while I steal with my right. The DoS has so much focus of the organization, secondary routes into the system (physical, social, or technical) could be undermanned, provisioned or systems can be more easily by-passed without being noticed.
DoS attack could be a plant. I once heard of hacker who conducted a limited DoS attack on organization A, because he had done his research, and the CIO from organization A was very close to organization B, and both organizations were in the same general business arena. So he suspected that if he could get organization A to adopt a specific technology to thwart his rather crude DoS attack, that organization B would do the same - thinking they might be next. He was very correct, as organization B did. Why? Well the hacker had an 0day exploit in the piece of technology and he wanted to attack organization B.
Secondary Route/Bridging Exploitation. An extended DoS attack that can be sustained, can force business units within the organization to move to secondary systems paths (networks) to keep critical business going. While some of these secondary paths may be well-planned and secured, many are not. For instance a business unit may stand up a wifi, or mifi device and start using it as their business network without any security infrastructure. If an attacker is actively monitoring and profiling, they may be able to capture and attack these very vulnerable paths and now you have a direct, totally unsecured bridged network into the organizations intranet.


SQL injection: how to find urls to attack to The last days I've been reading about SQL injection and most of the url examples I see are like the following:

get_int_filtered.php?id=1
get_int_groupby.php?id=1
get_int_having.php?id=1
get_int_img.php?id=1
get_int_inline.php?id=SELECT+name+FROM+users

(The above are a small example included in the: sqlmapproject/testenv)

I'm missing the part of how someone discovers these urls to attack to. Is it a manual task? For example, by checking the browser developer tools to see the calls to the backend / REST api of a website? Is there a tool that can scan a website and provide a list of urls and HTTP methods to try with (as a second step)?

SQL injection: how to find urls weak to SQL Injection attacks.

First, you have to understand the different types of SQLi, here.

I will speak here about In-band Injection, the classic one. divided into 2 types:

Error based SQLi
UNION based SQLi

Error Based SQLI

Goal: Gathering database structure information by Displaying SQL Errors on the target website. In some cases, you can enumerate the entire database with those.

Finding a weak URL: Using Google Dorks. Yes, google is helping you finding weak urls.

example: inurl:"product.php?id=" site:.ru

Here you are asking Google to list Russian site with product.php?id= in the URL.

Why?

Because we want to find a page which is directly talking to the database. In most of the case you want to search for those patterns: *.php?parameter=n

Alright, but how do I know this URL is weak to SQLi?

You have to put a ' or %27 just after the parameter's number and press enter:

http[:]//w34ksite.com/product.php?id=1'

If a SQL Error appears there is some probability that this website is injectable.

UNION Based SQLI

Goal: Leverages the UNION SQL operator to combine the results of two or more SELECT statements into a single result.

the following block is a material I wrote for my infoSec students.(Offensive security class)

weak site:

http://w34ksite.com

first step

Find an URL that potentially sends SQL queries, like this one:

http://w34ksite.com/products.php?category=1 this URL list products, regrouped in the category named 1

Try to remember that an URL ending with * ? * = * will, in most cases, communicate with a SQL Database, we want to exploit this.

The second step

Translate the products.php?category=1 part of URL into a SQL query. Yes, in this scenario (and in a lot of website in production) this piece of URL is a disguised SQL query:

products.php?category=1 --> SELECT * FROM products WHERE category=1

The third step

Can we inject the category parameter? Let's try to sort the products list by adding ORDER BY n, for instance :

http://w34ksite.com/products.php?category=1 ORDER BY 1 Nothing change.

http://w34ksite.com/products.php?category=1 ORDER BY 2 Wow ! the products order have changed! We probably can inject stuff!

The n number in ORDER BY n indicate from which table's column number you are sorting the output (in this case the product's table column 2). So wait a minute, what happens if I input a number that exceeds the max number of the table? Let's try out.

http://w34ksite.com/products.php?category=1 ORDER BY 3 Order changes again.

http://w34ksite.com/products.php?category=1 ORDER BY 4 Wow! Blank page! We can deduce that the product's table has 3 column. This info is crucial for using the SQL UNION ALL operator.

The fourth step

Planning the attack. So, for example, we want to dump email addresses written in this database. And of course, the email entries are not in the product table. They should be elsewhere... You can guess table's name and more when SQL error appear directly on the web page, but no luck this time, no SQL error appears on w34ksite.com. So let's assume the email's table is named email, because we know this is this CMS default email's table name.

SELECT * FROM email --> http://w34ksite.com/email.php? Of course not. Who will be crazy enough to create a PHP page that lists the database's email? Why not password.php?

Don't forget that products.php?category=1 is our key to communicate with the database and inject things. This key open the database door, the general idea will be to use this key for displaying the content of the email table. So why not displaying the product table content (products.php?category=1) and the email table content? Yes, this is what we will do. By using the UNION ALL operator.

The UNION ALL is quite useful, you can join another SQL request by using it. For instance, let's translate again this URL part into SQL:

products.php?category=1 --> SELECT * FROM products WHERE category=1 right ?

We will now add the new query by using the UNION ALL operator and try to fetch the email table :

SELECT * FROM products WHERE category=1 AND UNION ALL SELECT *, NULL, NULL FROM email

We should have something like this :

http://w34ksite.com/products.php?category=1 UNION ALL SELECT *, NULL, NULL FROM email

Wait, what is the  *, NULL, NULL ?

Remember the http://w34ksite.com/products.php?category=1 ORDER BY 4 for testing if we can inject thing? We get a very valuable information: the number of column the product's table have. When using the UNION ALL operator, the table's column number has to be the same.

NULL: Fake an empty column.
, : Separate a column from another
* : display entries of this column

If nothing happens, try to move the * around like this:

http://w34ksite.com/products.php?category=1 UNION ALL SELECT *, NULL, NULL FROM email

http://w34ksite.com/products.php?category=1 UNION ALL SELECT NULL, *, NULL FROM email

http://w34ksite.com/products.php?category=1 UNION ALL SELECT NULL, NULL, * FROM email


Simple way to safely paste text from website into terminal It's fairly well known that it's very dangerous to copy-paste text from a website into a terminal, as it can include extra text, control codes, and newlines that aren't visible when you're copying it, but which are saved into the paste buffer, causing malicious code to execute if pasted into a terminal.
The above-linked website contains the following HTML and CSS:

  git clone
  /dev/null; clear; echo -n "Hello ";whoami|tr -d '\n';echo -e '!\nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';head -n1 /etc/passwd
git clone
  git://git.kernel.org/pub/scm/utils/kup/kup.git

This renders as git clone git://git.kernel.org/pub/scm/utils/kup/kup.git, but when you highlight and copy it, it pastes multiple lines into a terminal, causing them to be executed:
git clone /dev/null; clear; echo -n "Hello ";whoami|tr -d '\n';echo -e '!\nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.git

Is there any simple, fast way to get around this for single-line strings? For example, copying the text, pasting it into the browser's search bar, and copying it from there seems to remove all newlines:
git clone /dev/null; clear; echo -n "Hello ";whoami|tr -d '\n';echo -e '!\nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!Here'"'"'s the first line of your /etc/passwd: ';head -n1 /etc/passwdgit clone git://git.kernel.org/pub/scm/utils/kup/kup.git

Now you would have to explicitly press enter in order to cause the code to execute, and the act of pasting it into the terminal is not enough. Is this a safe way to protect from all variants of this attack?

I'm going to write an answer because comments would be too long, even though I'm not sure this is the answer you are looking for.
It sounds like you want a quick way to paste code into the terminal, yet I don't understand why you want to be quick when you are doing something that is clearly very dangerous, and it's also something that I suppose (and hope) you are not going to do too often. I mean, if you trust the source you can just copy and paste the code directly, but since you are clearly talking about sources that you don't trust (and which might use "tricks" to hide code inside text strings), why do you even want to be quick? You should actually want to slow down.
In the comments I suggested using a text editor to check the strings, but on second thought and after some tests I believe you can't even trust text editors in general after all. What can be done depends on the terminal (emulator) you use, and your text editor. My terminal apparently removes the escape character needed for ANSI codes from the command line, so I cannot use "invisible text" or move the cursor in the command (but it's possible of course to do this in the output). The following command can't be pasted for example, because the ANSI code is removed:
# ESC is 0x1B, the first code sets invisible text, the last resets it
echo foobar; ESC[8m echo hacked!; ESC[0m

If ANSI code worked, it would be possible to add invisible code at the end of a command, and then maybe move the cursor back to avoid the suspicious space before the prompt. Do all terminals behave this way? I don't know, but I don't think we should trust them all.
My terminal also removes the Unicode char U+202E (Right-to-left override) and U+202D (Left-to-right override). This means that the result might be going to be different than what you see and expect. For example:
 # The following string will appear as "echo rm;"
 # when seen in an environment that interprets those chars
 echo\u202E;\u202D rm

 # However when you copy it and paste it to an environment
 # that strips those chars off (like my terminal), you will get:
 echo; rm

It might be difficult to find tricks to execute arbitrary code, and what you can achieve might be limited, however it's still a sign that things can go wrong and newline chars might not be the only characters we need to worry about.
In fact, other chars we definitely need to worry about are non-ASCII chars that allow homograph attacks when URLs are involved. All modern browsers will show the real address today, but in a terminal I'm afraid there's no way to know what you are actually going to do before you hit enter:
# Here the first "e" is a Cyrillic letter
curl 'https://www.еxample.com'
Could not resolve host: www.xn--xample-2of.com

A text editor might or might not help in all cases (it depends on what it can display and how it is set up). A hex editor will always help, and it's probably what I would recommend: save the untrusted code in a file, then inspect it with a hex editor. Another quick solution could be be a custom script that makes sure all the input chars are printable ASCII chars, and if not, it warns you. You could use xclip for getting the input from the clipboard, grep for checking the input (if anything outside the printable ASCII range is found, print a warning, otherwise print a confirmation that the input is ok), notify-send or zenity to display desktop notifications. Configure some keyboard shortcuts to run it easily.


Implementing an autologin link in an email So I'm working on a PHP application called Magento and I would like to implement a link which will be sent in an email to customers that will automatically log them in.

I know it is critical in terms of security so here's what I came up with so far:

store the generated links in a database table
generate a random token value stored against the customer id
both token and customer id in the URL
in case the token does not match the one stored for the customer id, reset the token (to avoid brute forcing)
make the links one use only
set an expiration time on the links

I want to avoid the use of a second factor such as a PIN code to keep it as simple as possible for the customer but security matters so it's hard to find the right balance.

I know that Slack has a magic link sent by email when you don't want to type your password. The idea here would be something similar.

I'm looking for any recommendation on this approach, and how can I improve it ? What did I miss ? What are the risks left with such approach and how to overcome them ?

The token should have at least 72 bits of entropy (9 bytes, or 12 Base64 characters)
This should be generated with a Secure PSRNG (random number generator). So don't use the simple rand() operator of your programming language as it might be predictable, but look for the Secure random generator that PHP provides internally , or read bytes from /dev/urandom

store the generated links in a database table

It is best not to store the plain token in the database, in case the database is partially stolen . Instead, store an SHA-256 hash of the token, so that the only copy of the original token is found in the email you sent to the customer.
Note that Hashing is also common for passwords, but since passwords have less entropy you would normally use BCrypt. Since the tokens have 72 bits of entropy, the fast SHA hash will do fine.

both token and customer id in the URL
in case the token does not match the one stored for the customer id, reset the token (to avoid brute forcing)

I would say this is not needed. With 72 bits of entropy, it will be near-impossible to brute-force the token.
Also this scheme suggests that any unauthorized person could reset tokens this way, which is a form of DOS attack. (not hacking in, but preventing others from being able to use the system)

make the links one use only

This is a good choice, because the link will be stored in browser history unfortunately.

set an expiration time on the links

Certainly a good idea.
Do note however, that the weakest link is the ability for someone to hack your customer's Email (which is usually synced across multiple devices), so this is not sufficient security for many situations, but may be acceptable in your case. That is your decision.

I'm looking for any recommendation on this approach, and how can I improve it ? What did I miss ? What are the risks left with such approach and how to overcome them ?

I've outlined what you missed above and the primary risk of using this approach overall. However I would add that you should limit the amount of emails a person will receive. You don't want a robot filling out your Forgot Password form too many times thereby spamming your customer.
There are many other security considerations related to session management as well as authentication itself but that is beyond the scope of this answer.


Increased HEAD traffic to my website In the last few weeks I have been getting an increased HEAD traffic to my website of the form

HEAD / HTTP/1.0" 200 0 "-" "-"

This just returns the details of my web server, right?

The IPs are from all over the world. Any idea on why this started suddenly?
I do get the usual attacks infrequently, but this HEAD traffic is roughly 2 per hour
for the last 2 weeks.

Should I be worried? I find it hard to believe someone is trying to hack my website
from Ouagadougou, Burkina Faso.

Has anyone else seen something similar recently?

No, you shouldn't be worried, especially not at the rate of HEAD HTTP requests that you're quoting. One such request every half an hour on average is really not much. Basically, HEAD requests do what it says on the box, that is, your web server will only return response headers and will not attach to it the complete response body. This can be useful to lower bandwidth requirements for simple tasks of e.g. establishing response code for requested location, client cache validation, and so on. That can then be used to either establish that your web server is responding, or if the requested location is still available, not re-send contents that weren't changed in the mean time and are already locally cached by the client,... depending on your server's response HTTP status code and header contents.

Now, these requests can be rather frequent and sometimes a bit annoying in quantity, but they're technically for your server better in terms of consuming its resources, since a well written web host can process such requests faster and consume less upload bandwidth to send back a response, than if it had to process and include in its response a complete document. With larger media files, this gets even more apparent. So I wouldn't advise to block such requests in your web server configuration, and if they make your server's log files less readable, I recommend you pipe such requests into a separate log file.

As far as what's returned in these headers, there's nothing much different in them that with the normal GET requests, with the exception that the content length will be obviously smaller. And there is no reason to think that increase in HEAD HTTP requests is some form of a DOS attack on your server, since it would take the same effort for the attacker to send GET requests, while at the same time exhaust your server's resources much faster. The only case when HEAD would do that faster than GET is if you don't rate limit or block by other means (e.g.request IP) the former, but you rate limit or filter the latter and a few other common HTTP request types like e.g. POST, which would be a case of misconfiguration and isn't really frequent. Do make sure you don't unwittingly disable any such filtering in your configuration for less common request methods tho, just to be sure.

So if you should block HEAD requests is up to you, but I wouldn't bother. There are other HTTP request types that are a lot more worrying, especially if you don't even have any use for them on your host, for example TRACE, SEARCH,OPTIONS,... And it is always a good practice to disable response to all HTTP request methods that your server software doesn't have any use for. For example, this is from my Apache config:

RewriteCond %{REQUEST_METHOD} ^(TRACE|SEARCH|TRACK|OPTIONS|PUT|QUIT|CONNECT|DELETE|PATCH|DEBUG|PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)
RewriteRule .* - [F]

This assures that none of the methods listed are served (request forwarded from the web server software to the application handling these requests and processing them) and the web server immediately denies them by returning a 403 Forbidden status code to the client. Do note though that your web applications might be written to require some of the HTTP methods that I block in my configuration, this example is not meant to be copied directly and can break functionality of your web host, if not used with caution!


Approximately how much entropy/security is lost by typing passphrase words using a number pad? For context, the coldcard hardware wallet has a number pad as input. In order to maintain my sanity, I'd like to input an alphanumeric passphrase using a single keypress for each letter or number.

So for example, the password "boyhowdy123" would be typed "26946939123".

I know that doing this loses some security (becomes easier to brute force crack) based on the number of words (or word sequences) that have the same numeric representation using this method as other words (or sequences).

My question is: approximately how much security is lost here? Am I missing anything that also affects the security of doing this? Is there anything published that analyses this kind of thing?

tl/dr: This method hurts your password strength quite a lot due to the loss of characters (mainly since 0 and 1 are often left out when
entering letters through a numeric pinpad).  However, trying to brute
force a password here is slow, so with a long enough password you'll
be fine anyway.

Analysis
You already seem to know the answer, but I'll spell it out with a bit more detail in hopes that this is helpful.
Unfortunately, your selected method of password generation will, quite possibly, generate the lowest possible amount of entropy. Obviously you would get less entropy by picking a clearly bad password, but this method still gives pretty poor results.
The best way to see this is by comparing against it's entropy ceiling - a pure digit password. That's a simple one. If all you have is numbers then you have 10^n possibile passwords, where n is the number of digits in your password. A 4 digit password has 10,000 possible combinations, etc...
In your case though your numbers are determined by conversion from letters. As you know, the English language doesn't use letters evenly, resulting in a loss of entropy. It would be difficult to determine exactly how much entropy is lost, so a good paper would be required. I don't have one of those though, but I can still guestimate!

You lose at least 1 number because in most letter mapping systems the 0 is unused
Many telephone keypads leave the 1 unused as well
And of course the variation in frequency hurts. Harder to estimate so I'll just knock off another digit and call it a day

You'll effectively lose 2-3 possible characters out of the 10 you have.  This actually takes a big hit out of your entropy, because the number of possible passwords is determined by [Number of characters]^[Password Length].  The presence of that exponent makes this very non-linear, as we'll see below.
Brute-forcing
Is this a deal breaker though? That depends!
Deciding how difficult a password is to crack depends on two things: the number of possible passwords, and the rate at which an attacker can guess passwords.  Both can be determined accurately enough in this case.  First, how many possible passwords are there?  Let's assume you end up with a 12 character password, and let's compare against three passwords: randomly chosen numbers and characters, randomly chosen numbers, and random numbers without 0 and 1.
We also need to know how fast an attacker can run through passwords.  Just for kicks, I'm going to compare two speeds: the rate at which a high-end GPU hashing rig can crack MD5 hashes (200GH/s), and the rate at which a very experienced person can enter numbers into a pinpad.  Obviously the former (the MD5 hashing rig) is not in the least bit applicable here, but I want to include it because I think it will give a helpful reference.  For pinpad entry, it's hard to guess exactly how fast an attacker can enter passwords, but we'll be generous and give them 10 guesses per second.  Here are our numbers:

12 character alpha numeric password.  Number of possible passwords: 62^12 = 3e21 (entropy = log2(3e21) = 71 bits of entropy)
12 character numeric password.  Number of possible passwords: 10^12 = 1e12 (entropy = log2(1e12) = 39 bits of entropy
12 character numeric password (but without 1 and 0). Number of possible passwords: 8^12 = 6.9e10 (entropy = log2(6.9e10) = 36 bits of entropy.

Against a cracking rig
Our cracking rig can check 200,000,000,000 (aka 2e11) passwords per second.  Simply divide the number of passwords by the hashing rate to get how long it will take to crack it:

Alpha numeric: 3e21/2e11 = 1e10 seconds = 511 years
All numbers: 1e12/2e11 = 5 seconds
Numbers without 1 & 0: 6.9e10/2e11 = 0.3 seconds

As you can see, there is a huge difference in their cracking times.  For reference, some websites still use plain MD5 for storing passwords, so the above math is why using a long, random password is required.  Of course an attacker can't just hook your wallet up to a GPU cracking rig and run through guesses that quickly.
Hand entry
Instead the passwords have to be entered by hand, so we'll try again with our 10 passwords per second rate (which is probably very generous):

Alpha-numeric: 3e21/10 = 3e20 seconds = ~700 times the age of the universe
All digits: 1e12/10 = 1e11 seconds = ~30 centuries
Numbers without 1 & 0: 6.9e10/10 = 6.9e9 seconds = 2 centuries

Your password is still quite uncrackable under these circumstances, but it is worth noting that losing just 2 out of 10 possible characters reduced the cracking time by a factor of 15!
The above analysis assumes a full brute-force search of the entire password space.  For a long diceware-style password that is actually quite unrealistic, and an attacker would be better off working off of the actual word list.  In that case, a more detailed analysis from the OP shows that the loss of entropy is much smaller.  Either way though the overall summary remains the same:
Summary
So your chosen method definitely weakens the password.  However, given that these passwords have to be manually entered (and therefore password cracking is quite slow), you can still get sufficiently secure passwords even with this method, as long as it is long enough.
Personally though, since we're talking about a potentially high-value target that someone has to physically steal, I'd be more worried about rubber-hose cryptanalysis.


What are the risks of just clearing cookies instead of logging off? A typical web authentication workflow looks like this:

User provides their credentials.
Server validates credentials.
If credentials are valid

Server generates a token.
Server keeps this token.
Server responds to the login with this token.

Browser stores token.
Browser makes requests with token.
Server validates token and responds accordingly.

Normally, this token is stored in a cookie. The presence and validity of the token in a request lets the server know if the client making the request is authenticated. No token, no entry, which is effectively the same as not being logged in. So...

Can I just log out by wiping cookies instead of hitting logout?
What are the issues of just wiping cookies versus clicking the logout button?

Can I just log out by wiping cookies instead of hitting logout?

Frequently yes, for the reasons you supplied in your question: Without the session token in your cookies, a typical web application won't know who you are.

  What are the issues of just wiping cookies versus clicking the logout button?

Web applications that manage authentication following the OWASP session management guidelines will invalidate the session on the server side when you log out explicitly.  If you simply discard the cookie with the session token, the session may be subject to session hijacking.

Using door locks as an analogy for those who are not familiar with best practices of developing web applications (thanks to discussion in the comments):

Your account can be seen as a room in a building. When you log in, the building's owner creates a door and puts an automatic lock on it, so that only you can enter.  Your session token is your key, and is typically stored in your browser's cookies, but can be stored in other places.

Discarding your token by deleting your cookies, clearing cache, etc., is simply destroying your copy of the key.

Explicitly logging off is asking the building owner to brick up the doorway. There's nothing guaranteeing that they'll secure your account, but as the user, you're explicitly making your wishes known.

There are various ways that an attacker can get a copy of your key, known as session hijacking, that are the responsibility of the site owner to mitigate, not the users.

First, the attacker can just guess. If the site generates session keys sequentially, or uses a low entropy pseudorandom generation method, this makes guessing much easier. Sites mitigate this through using high entropy tokens and periodic session recycling. Recycling sessions doesn't prevent access, but it makes it obvious when unauthorized access has been granted.

Second, the attacker can use session fixation: They give you a key before you log in, which you continue to use after you've logged in. Sites mitigate this by explicitly recycling the session when you log in.

Third, a Man-in-the-Middle attack. The attacker can see your key directly.  TLS mitigates this. It is possible to decrypt TLS traffic through downgrade attacks, insecure implementations, and zero-day attacks, but these are far outside a user's domain, rare, and zero-day attacks against TLS tend to raise a LOT of noise when they're discovered (Heartbleed, et al).

As a user, your responsibilities are to log off and to hold the site accountable when they take shortcuts with security, much as your responsibility with your car in a public parking lot is to lock your doors.  If the door locks are trivially bypassed, then its the manufacturer's fault, not yours.