How do EMV contactless cards protect against replay attacks?

The most-authoritative reference on EMV replay (i.e., transaction cloning) is Peter Fillmore's latest talk from Syscan 2015

https://github.com/peterfillmore/Talk-Stuff/blob/master/Syscan2015/PeterFillmore_Syscan2015.pdf

Another great resource is Ricardo Rodriguez's talk from Rooted 2015

http://www.slideshare.net/cgvwzq/on-relaying-nfc-payment-transactions-using-android-devices

Which mentions the NFC Proxy talk from DEF CON 20 by Eddie Lee

https://youtu.be/tFi0vYuYeAI

Of additional interest is Ricardo Rodriguez's whitepaper on EMV relay attacks

http://conference.hitb.org/hitbsecconf2015ams/materials/Whitepapers/Relay%20Attacks%20in%20EMV%20Contactless%20Cards%20with%20Android%20OTS%20Devices.pdf

and Ricardo Rodriguez's website

http://vwzq.net

Some additional validation of these attacks was provided during a HackFu competition by MWR InfoSec

https://hackfu.mwrinfosecurity.com/hackfu-blog/params/post/465447/how-to-hack-a-contactless-payment-system.html

And finally, Michael Roland and Josef Langer write about the downgrade attacks against EMV, as well as the protections built into the protocol. As you can see, originally, the EMV contactless spec itself wanted to provide the protection (long before payment validation), but things don't always work out as planned.

http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12055-woot13-roland.pdf


IPv6 is just advanced addressing and networking protocol. With respect to Multicast Traffic and related security it will not provide any specific solution.

There are various encryption available for securing the Multicast Traffic. Cisco has implemented it in its IOS. Cisco IOS® Secure Multicast is native IP Multicast encryption that does not rely on a tunnel-based architecture, lowering administrative overhead and helping ensure optimum WAN flexibility.

Application level security and encryption can also be implied in order to secure generated Multicast Traffic. Cisco has published in depth analysis of Threats in the Multicast Environment and Securing a Multicast Network as The Multicast Security Tool Kit  you can refer that for more.


WebSecurity and StrictHttpFirewall in spring

All of the attacks you referenced can all be mitigated with user input validation.

Don't want your site attacking another site?  Then don't allow certain command characters so they can't construct scripts do to do.  Do explicit checking to search for commong behaviors for XSS.  Search for the  tags and Javascript code.

SQL Injection can also be mitigated by user input validation.  Make sure that if you're looking for a persons name in a variable, you're only allowing characters appropriate for the names you want (no extraneous characters:  <, >, $, %, *, etc.).  You can also help mitigate this by using a database user who has catered access to the tables in question:  SELECT and INSERT but not DELETE, etc.


When a user tries to register with an unactivated email again, should I tell user that the emails has not been activated?

You should never reveal on the website, whether a specific e-mail address has been used to register. This allows a user enumeration attack and may likely be a privacy issue for your users.

Instead, in your case, send an informational e-mail to the address in question.


How to enable DH_RSA instead of DHE_RSA?

Fixed DH means a DH certificate. Nobody uses this. You want DHE with RSA certificate. Actually, you want ECDHE over NIST P-256 for compatibility and X25519 for security and performance with modern browsers. New versions of Google Chrome don't support DHE.

If you use DHE (which I think your server should support), your server should generate safe params with same bit size as the RSA key in the certificate (generally 2048 bits). With nginx, you should use openssl dhparam command to generate a file and ssl_dhparam nginx configuration statement to point to that file. Other web servers and TLS terminators have different methods of generating safe DH params of appropriate size.


Tracking phone in country when SIM is not supported

Supported SIM or not, triangulation can still occur from the device pinging off of towers or signals, even if there is no data being moved across those specific mediums. This is an example you can look into, and is something the US has done overseas with drone activity. This is a broad question. Most likely though, it wouldn't be the police.

Another thing to consider is if you do use a network like WiFi, even if it's a new phone: connecting to accounts that can verify your identity (bank, social media, etc.) will also point to you. Very similar to opsec within VPN/Tor usage. If you have more specifics, feel free to ask. Otherwise you're going to get very broad answers.


Begin each session by having the client generate a symmetric encryption key, encrypt it with the public key of the server, and send it to the server. Both server and client can then encrypt all further communication during the session with that symmetric key.

An impostor server would not have the private key of the server, so it can not decrypt the session-key and thus can not communicate with the client.

By the way, you are currently reinventing TLS with certificate pinning. You should generally avoid inventing your own cryptographic systems. Use what's already there and already tested for vulnerabilities by countless people.


Best practices for securing an android device

Use the features already on the phone as your first choice. The features on the phone:

Are battle-hardened technology.
Don't require Apps from third parties.
Are very well embedded in the Operating System.
Usually provide great value for money and effort.
Just don't look as sexy as additional features (they don't have the marketing budget).

Other Recommendations.

Screen lock / password. ( Make your password strong enough that it cant be easily guessed / compromised, my daughter cracked my complex pattern password easily, so don't use pattern passwords and probably not pin passwords)
Only allowing Known Sources (i.e Android Market), remember that an application is a major attack vector.
Don't load hacked applications ;)
Don't load many applications at all.
Dont root your phone.
Use a password manager on your phone. I recommend Android LastPass myself as it encrypts at rest, but the password has to be entered on demand to make this very secure.
Unless you have a secure folder as @Traroth mentions, everything on the sim card can be retrieved by your attacker (and malware is probably able to read encrypted content when you unlock the encrypted volume, this goes for a password manager too).
Remote Wipe (Google Play and a lot of other services offer this).
Don't select "Always" for important functionality like 'Send SMS', because this can allow a compromised application to send paid-for-sms without user intervention.

Remember that each of these security technologies offer an improvement in security. But equally, they also can provide a avenue for compromise.

Remote wipe and other 'control' tools can also maliciously wipe your phone if the account/service is compromised.
If the Application provider is compromised, then the malware enabled application can cause a lot of mischief.

Updated for 2018:

Encrypted storage. Allows for (among other things) simple and complete device wipe.
Fingerprint unlock. Can ensure much better usability, but can also allow bully-boys to physically force you to unlock your phone.


It is difficult to provide a single complete answer because there are too many variables and what may work for one model/brand may not work for another. The term 'Smart TV' is also poorly defined and not all of them 'call home' - many don't even have a built in webcam or microphone.

The first question you need to ask is "What do you want/expect" from your Smart TV? This will help determine what features you need and that will help determine what options you have available. The other question you need to ask is what is the threat you are concerned about? Are you concerned about the neighbours or passes by who may overhear your conversation through that open window? What is your real concern should it be true that the vendor is recording your conversations through the microphone on the TV? Likewise with the camera.

This isn't to say you may not have real things to be concerned about, but it probably needs to be a little more than just an abstract concern. Some people, such as celebrities, politicians, secret agents and crime bosses probably have more real concern than most of us. Knowing what the individual risk is determines what level of protection/concern you need to have.

It is also important to consider the other side of the coin. Consider the perspective from the vendor. Lets say you produce a smart TV and it collects lots of data, such as recording the sound and vision in the room. Now consider they have sold 2 million of those TVs, so have data coming in from 2 million users. That is a hell of a lot of data. However, having data and being able to make use of it are two vary different things. That is a lot of processing.  How you use/process the data is also worth considering. Processing a lot of audio streams to improve algorithms used in natural language processing and voice recognition is one thing, processing the streams to extract real meaning and then using that information effectively is another. All of this also comes at a high financial cost, so there has to be some real financial benefit.

All of this isn't to say there are not real concerns. As the NSA has demonstrated, processing and extracting meaningful data from large data sets is vary possible and there are some real concerns regarding what some of these vendors are doing and how they are using or even securing the data they collect. However, to what extent this is a real threat to an average individual right now is uncertain, but likely low.

We also need to balance all of this with the real potential for benefit from this data collection. Most of us would really like devices which have reliable and accurate speech recognition or smart devices which are able to work out what we want to watch, what products we are really interested in etc. What most people hate about advertising is that most of it is junk we are not interested in. If all the ads you were shown were for things you are interested in, you wouldn't mind as much. To achieve this sort of benefit, the manufacturers need data to drive the research. If we want devices which improve, we need to let the manufacturers have more data about how we use the device, where the device fails, has errors, crashes etc and we want the manufacturers to send us updates and improvements.

So, what do we do?

Select a device from the manufacturer which has the best terms and conditions. Look for one that actually has privacy statements, tells you what data they will collect, how long they will keep it, what they will use it for and how they will store it. Yes, we are trusting they are being honest, but why should we assume they won't be? What is the benefit in them being dishonest? If they have a privacy statement and reasonable terms and conditions, at least we know they have thought about it. Most of the problems with IoT devices is that the vendor simply has not considered these issues.
Depending on your setup, you will normally configure your router/modem to have a firewall which blocks all incoming connections. These are connections which are initiated from outside your network and try to connect into devices within your network. Most of the services you are likely to want have connections initiated from inside your network going out. Exceptions are things like an audio chat service which allows your friends to contact you. Connecting to things like TV streaming services are typically initiated by you and don't need to be initiated from external sources.
Look for a device which has the option to enable or disable data collection. These days, many software and operating systems have this sort of feature. You can decide to opt in or opt out. Go for a vendor who lets you make this decision.
If you are still uncomfortable, just don't connect the device to the network. I've looked at a number of 'Smart TVs' and in fact have 3 of them. However, none of them are connected to the network. This isn't because Im paranoid. The main reason is that so far, I've found the quality, reliability and usability of all of these smart tv apps to be far inferior to the equivalent functionality provided by my PVR, xbox, ps4 or chromecast. Right now, smart tvs seem to be more hype than benefit. This will change, but I can't see the quality reaching the same level as other devices for a couple of generations yet and lets face it, you tend to replace your TV less frequently than other devices, such as laptops or tablets.

We all need to be more concerned about data collection and privacy. However, we also need to be wary of becoming too paranoid. What we really want is informed consent and some guarantees about how the data will be sued, stored and eventually destroyed. The only way to get this is through our choices. Be willing to pay more for better, secure and informed choice. Be prepared to not purchase the device if we are not happy about the company's practices or the way it may use our data. Be willing to forgo convenience to ensure we have privacy and control.


GSM - Implementing Cipher Mode Command on YateBTS

The YateBTS Wiki states the MBTS software supports Ciphering for A5/1 and A5/3 in the air interface, though not the A5/2 you have mentioned, perhaps this implimentaion would suit your needs?

MBTS features


The htaccess files possibly get regenerated by the webserver when the request is made to a specific entry point. This should be a commonly used file, such as index.php.

Find and remove the relevant code from the webapp files. If you have shell access,

grep -rnw '/var/www/whatever/path-to-your-webroot' -e "deade6"

It worths having a look at /var/log/apache2/error.log and /var/log/apache2/access.log (or find an equivalent log menu at your hosting provider) as well.

Also, if nothing works, in the very final case, you can still install nginx, which ignores .htaccess, so the pages dont get the malicious php rendered while you can work on fixing the issue.


No. There's no difference between appending them in a single field or using different fields in the db. Use whatever you find simpler in your code or more consistent with your style. Conceptually, you may prefer to treat them as two different entities, while often you simply treat that field as a black box than only some inner functions use (and know how to split). It really doesn't matter the way you choose.


How does WPA2-PSK prevent evil twin password phishing?

No password is ever sent during the 4-way handshake, therefore it cannot be phished.

When a client connects to an access point (AP) using WPA2-PSK, the password or pre-shared key (PSK) is, as the name suggests, already known by both parties. So there is no need to exchange it again.

Do not confuse this with other scenarios where no pre-shared secret is available. (Say, you're connecting to a website via SSL and need to perform a Diffie-Hellman key exchange beforehand.)

Naively, the client and AP could simply go along and use symmetric encryption (e.g. AES) to communicate confidentially. They would use the PSK as the only encryption key without any preceding handshakes or additional key exchanges. However, this approach is flawed since it uses the same key for evey message and neither party had to prove its identity, thus opening the door for replay attacks, etc.

So, the purpose of the 4-way handshake is not to exchange a passphrase, but to prove to the other party that you actually know the PSK (respectively, a PMK which you can consider equivalent here) and establish a pairwise transient key (PTK). This PTK combines the keys that will be finally used for the actual encrypted data transfer.

The proof of knowing the PSK happens when both parties use it to generate a message integrity code (MIC) that will be sent along with the random nonce values during the handshake. Therefore, a handshake between your evil twin and a legitimate client would look like this:

Your rogue AP generates a random nonce (ANonce) and sends it to the client.
The client chooses a nonce (SNonce) and is now able to compute the PTK. It sends the nonce along with a MIC generated from the key.
Now your AP has to send back a group temporal key (GTK) with the corresponding MIC. Since you can't generate the MIC without knowing the PSK, the client will reject your response and the authentication fails.


Can a TPM's EK's public key (hash) be used to fingerprint a device?

EK cannot be reset. It is this certificate that identifies the TPM as being real/trustworthy (e.g. not software-based) and TCG compliant.

The statement about EK being private refers to a 3rd party in the context of remote attestation - not someone already on the local machine which as many other means to fingerprint the device.

In other words, if you were to do remote attestation via the EK directly, you would always expose the same identity. With AIK, you can have as many identities as you want and only the CA knows your real identity (public EK).

So the answer is NO in the context of remote attestation and YES in the context of someone already on your system.


The pastebin posts help a lot.  First of all, we see from the unsanitized user inputs that you posted, that the spammer actually isn't entering inputs containing the @ character, after all, in 'name' field of your form.  So that explains how it's getting past that check in your script.

It seems that what's happening is that your MTA is appending @yourdomain.com to these inputs, which is what MTA's default to doing when they encounter an email address without a domain.

So, that brings us to the question of why your MTA is treating these values, in the From: header, where you would normally have the sender's name,  as email addresses instead of a name.  I think it's related to the way that you are constructing the $headers array that you are passing as the fourth input to the mail() function.  I think you need "\r\n" after each line in the headers, and the array needs to be converted to a string.  There may be other things to look out for as well.  See https://stackoverflow.com/questions/27478307/having-issue-on-setting-array-of-headers-in-php-mail-function for more info on how to get this right.

Update:  It turns out that in addition to the issues described above, problems were being caused if the user included a colon in the sender's name field when filling out the form, as this character later manifested itself in the From: header of the message.  See comments below by yaugenka for more info and for the solution.


What is the mechanism for this user impersonation?

Always go with the simplest choice.

Almost certainly it was a forged email with a legitimate (temporary) reply-to. No need for anything more complex. The staff at the bank use the same tools as everyone else for front-end customer contacts. Do you check reply-to addresses? No, neither do I & nor does the bank. Instead, they rely on their nested processes to mitigate the risk - which worked, so no problem. At least as far as the bank is concerned, they blocked the fraud and that is about all they need to do.

Whilst the bank could have been subject to a DNS-poisoning attack, this is quite unlikely and far too complex and costly for it to have been worth-while doing for such little return.


How to prevent my site from being hacked by learning from server log?

The IP goes to Quantil Networks. Quantil is the datacenter for UCWeb, the maker of UC Browser (the useragent used). This is very useful info.
There are ways to use Java to unmask a proxy user, but they are not foolproof. There are many questions here about how to do that.
An online useragent parser returns:

UC Browser 10 on Android (KitKat)
Samsung SM-G313HZ

Useragents can easily be changed or spoofed, but this is what this useragent means, real or not. Given where the IP is coming from, it is likely accurate.

None of these things will prevent attacks in the future, but they do help you understand who sent this attack. It looks like a UCBrowser user on a Samsung device using the UCWeb proxy. You could try reporting this abuse behavior to UCWeb and they might be able to look into it further.


I am not completely sure, but you may want to look at the protocol setting in sshd_config.

From http://wiki.centos.org/HowTos/Network/SecuringSSH

# Protocol 2,1
Protocol 2

Change Protocol 1 to Protocol 2 and restart. This should already be set to Protocol 2 in Centos 6.5, but you may want to double check.

I found this run down of the different protocol options

http://www.snailbook.com/faq/ssh-1-vs-2.auto.html

Not sure if that is going to be enough to solve your particular issue though.

Do you know what they are using to check the configuration?

UPDATED:

This is from running man sshd_config on

Ciphers
         Specifies the ciphers allowed for protocol version 2 in order of preference.  Multiple ciphers must be comma-separated.  The supported ciphers are
         “3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “arcfour128”, “arcfour256”, “arcfour”,
         “blowfish-cbc”, and “cast128-cbc”.  The default is:

            aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
            aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
            aes256-cbc,arcfour

Also the Macs option:

MACs    Specifies the MAC (message authentication code) algorithms in order of preference.  The MAC algorithm is used in protocol version 2 for data
         integrity protection.  Multiple algorithms must be comma-separated.  The default is:

               hmac-md5,hmac-sha1,umac-64@openssh.com,
               hmac-ripemd160,hmac-sha1-96,hmac-md5-96,
               hmac-sha2-256,hmac-sha2-512

So I would take a look through those and set the options in your /etc/ssh/sshd_config file with the ciphers and macs that you want.


Why don't websites and devices offer fake logins for hackers?

That way the hacker won't know if they have got the login details correct or not.

If the information presented after login has no relationship to the person who the login should be for, then most hackers will quickly recognize that the login is probably not the real one.

But, in order to show information which looks like it fits the user, considerable effort could be needed. It also needs to be created specifically for each user and show some true information about the user so it does not look fake but not too much so no important information is leaked.

You cannot expect your provider to do this for you but you might try to do this yourself in many cases, i.e. add another email account, another facebook account etc.


Yes, it is necesarry to keep the hashes secret.

For users with really good (long and random) passwords, a leaked hash might not be the worst that could happend, because it might be unfeasible to crack the hash anyway. But for users with bad (short and not so random) passwords, a leaked hash would in practice mean that their account is comrpomised. Anyone can easily brute force Passw0rd!, no matter how good your hash function are.

Hashing is an example of defence in depth - as a first defence, you do not want your passwords to be leaked, but in case they are anyway you want them to be properly hashed to minimize the damage.


SHA-1 how and when is it really a problem

An attacker creates an certificate for example.com and the SHA-1 value also equals X, so again, we have a collision, but this time it is not by any trustworthy CA!

The CA for a certificate is specified by the issuer field inside the certificate. The certificate is verified by looking for a trusted certificate which has this issuer as a subject and then use this certificate to validate the signature.

This means that if an attacker has a valid certificate which was signed with SHA-1 by a trusted CA and wants to use this signature for its own fake certificate the fake certificate needs to have both the same issuer information as the original certificate and result in the same SHA-1. If both is given this fake certificate is considered trusted same as the original one. Since the attacker has full control over the contents of the fake certificate he has also control of the issuer field and thus could set it as needed.


Can an SQL injection attack happen if the input is only allowed to be hexadecimal characters?

No, injection with just hexadecimal characters is not possible.

Another (better?) way to prevent SQL injection is to use prepared statements:

$stmt = $mysqli->prepare("SELECT * FROM User WHERE Password=?");
$stmt->bind_param("s", $password);
$stmt->execute();

Because you leave it to the database engine to correctly put your data in the SQL query, SQL injection is not possible. This way you don't have to worry about whether you have escaped all your data correctly.


Certificate chain with intermediate CA communication

1st question: In order to communicate with a desktop, should I also import the CA_INT2 to my laptops Trust Store?

not to Trust Store, but to a store where certificate chaining engine will search for missing intermediate certificates. Trust Store is supposed to store trust anchors (which are usually a self-signed certificates. In your case it is TA). This step may not be necessary if CA_INT2 provides information about its own certificate location in Authority Information Acess (AIA) extension. In this case, laptop will be able to fetch CA_INT2 certificate from presented desktop's certificate. It is a common and good practice to include AIA extension in all certificates to make it easier to obtain missing intermediate CA certificates.

  2nd question: Is there an option that desktop will include in his certificate whole it's chain (TA, CA_MID, CA_INT2) so that a laptop can verify that they both belong to the same trust anchor so I don't have to import CA_INT2 to the laptops store?

as was stated in the first answer, intermediate CA certificate can be obtained dynamically. However, in regards to this question: it depends. Depending on a communication protocol, server may send entire chain (except for root certificate) or leaf certificate only and you can't change this behavior. For example, when using HTTP over SSL/TLS, leaf and all intermediate certificates are sent to client. When using RDP over SSL/TLS, or using SSTP VPN, only leaf certificate is sent to client.

  3rd question: Is it possible to have communication between laptop and desktop when laptop has imported all the CAs (TA, CA_MID, CA_INT1, CA_INT2) and the desktop has only it's chain (TA, CA_MID and CA_INT2) imported? In this case I believe the communication can be only one way, am I right?

again, if intermediate certificates can be obtained dynamically (via AIA extension, underlying protocol or other available means), then everything will be ok.


Where can I find good resources on reversing web malware?

Check http://wepawet.iseclab.org/ is an online malware checker for URLs. It is worth reading their reports. A bit outdated but a good tool for hunting samples: http://malzilla.sourceforge.net/. Javascript deobfuscator: https://addons.mozilla.org/en-US/firefox/addon/javascript-deobfuscator/ and for a Javascript debugger look for Venkman or Firebug.

An online javascript "unpacker": http://jsunpack.jeek.org/dec/go and if you extract the shellcode you can emulate it on http://libemu.carnivore.it/


How eavesdropping will be performed how can I prevent from eavesdropping

Simply put - any unencrypted message which is sent can be seen by an attacker who has access to the communications channel. This can be more of a problem with a wireless network, as it is broadcast as opposed to a wired network, which would require an attacker to gain access to a point on the route.

The solutions to this are:

to encrypt the message
to encrypt the channel

Both work and are appropriate in different situations.

I'm not sure what you mean by barcode - a barcode isn't a security mechanism, it is a way of representing characters in a machine-readable format.

As to the uses of SSL - there are a wide range of questions here tagged SSL which are worth looking at.


Is there a domain specific language for security policies

I've used XML policies mostly.  But that's the world of web services --- I don't have an analogue in any other technology space, though.  Options include:

XACML - access control policy
Web Services Policy language - specs out WS-Policy and WS-PolicyAttachment - used for setting policies on how web services must be secured.

I'm fairly sure there are others in the web service space - but don't have links readily on hand.

In the lower layers - like lower layer firewalls - I don't have ready analogues.  I'm not such an expert in this space, but it seems like communication of policy implementation is vendor-dependant.

Appliciablity, so far as I can tell - is more about organizational boundaries and real world authority than technology options.  One of the nicer things about the web policies is that they can be varied across groups - so my high end server can have a tighter policy than a low-end server offering a similar service.


Yes, Wireshark will do the job.

If you want to sniff your own mails just start it on the corresponding interface.

If you want to sniff all mails in the network you have to somehow put yourself in a man in the middle position. You could use Cain for that if you have it installed anyway and it supports ARP poisoning, which is one possible method.

After sniffing for a while you can check "Statistics -> Conversations -> TCP" for the TCP sessions. In there you can select one and click on "Follow Stream" to see everything.

This will only work for unencrypted mails transfered over unencrypted protocols of course.


Would it be a good approach to hash twice?

There is always a chances of duplication's but most of the time the chance is fairly low (but higher than you would think, look at the birthday 'paradox')

Hashing twice will not give huge amounts of extra security, it is the security of hash 1 + security of hash 2.

To increase the security of password hashes you should salt them, this is give each password an individual random string to be appended to the password each time it is hashed, this will remove the threat of a pre-calculated table (rainbow table) revealing the passwords.

As mentioned in the security now podcast, there is nothing wrong with hashing passwords multiple times, actually it is encouraged because if you want to change the hash that your passwords are encrypted with, you dont have to wait for the password to be entered again to hash it with the new hash, you can hash all the old hashes with the new hash. This gives everyone the security of the new hash immediately.

I would also like to point out that MD5 and SHA-2 are bad hash functions for passwords. Password hash functions should be 'slow' and MD5 was designed to be fast (I don't know about SHA-2), you should use functions like Argon2, bcrypt, scrypt, or PBKDF2 which are really hard to speed up.


How does the authorization work after authentication using OpenID Connect

You only send the access token to the application server, the ID token is kept in the client.  And there's no reason why you cannot use a JWT as the access token. In this case, you can check the signature on the application server using the authorization server's public key.


Could an OS or app store and send my old IP after I start using a VPN?

Is it possible?

Yes. From context, I can tell you mean the public IP address(es) of your network (vs. RFC 1918 LAN IP). Since that isn't actually stored anywhere on your computer, determining this requires an active approach: the OS/app would connect to a peer on the Internet (could be microsoft.com in the case of Windows) in order to ask: "What address do you see me coming from?" STUN uses this approach. A less accurate method (pinpoint you to a region instead of a particular IP) that doesn't require coordination with some Internet server could be an early-aborted traceroute to obtain the IP of your ISP's last-mile hop.

Does this have a name?

Probably not. I'd call it some sort of "leak" like you did. It certainly hurts privacy.

Should I assume it happens?

Probably not for Windows. There's no reasonable way to do this without generating obvious network packets that draw attention. Even encrypted packets draw suspicion if they're headed somewhere you didn't authorize. Windows 10 does send a lot of data to the mother ship, but server-side client fingerprinting across ad networks for the sites you browse are more robust attacks against your privacy; note that a VPN is no use against browser/OS/user-agent/behavior fingerprinting.
You are also probably safe from this behavior if you use an open-source app/OS, as you (or the community at large) can review the code for anything nefarious. You can't do this for closed source code, so anything could theoretically be there.

How would I prevent against it?

The attack isn't very commonplace because it's fragile and risky compared to alternatives. If you pinpoint the servers or protocols used in the exfiltration, you could block the traffic using a host firewall (or your network firewall, if you can't trust your OS).


Can a browser extension (Chrome, Firefox, etc.) read the web console log?

Any extension that has access to the DOM can read whatever is written to the console by intercepting calls. The console is a JavaScript object; it is simple to proxy calls to console.log, like this example from zzzzBov on Stack Overflow:

(function () {
  var log = console.log;
  console.log = function () {
    log.call(this, 'My Console!!!');
    log.apply(this, Array.prototype.slice.call(arguments));
  };
}());

However I should note that intercepting console.log is not necessarily what you should be worried about. If an attacker is able to run their own code within your browser, they can do a lot of bad stuff whether or not the bank uses console.log. For more on that, see this question: Worst case scenario what can a Chrome extension do with "Your data on all websites"

But that said, if they've left console.log statements in their production site, that's a code smell.


Aren't the current implementations for multi-factor authentication heavily dependent on a single point of failure?

It all depends on what you want to secure yourself from. Typically, 2FA is meant to protect you from remote threats. Ones that cannot get access to your phone (99% of the planet).

If your phone becomes a single point of failure, then you need to secure that point using all the recommended features, like strong passwords, remote wipe, and encrypting the device.


Privacy implications of Intel CPU backdoors

You should catch up on these vulnerabilities in the canonical question on the subject.
Assuming you are talking about the recent wave of Spectre and Spectre-like vulnerabilities, those are not backdoors, but security vulnerabilities. They generally* allow a local process that is executing on your computer to read memory that they are not otherwise permitted to read. If your adversary is a nation-state actor though, this is the least of your concerns. These attackers usually have access to a large repository of 0days from security contractors. It's more likely that they will exploit a flaw in some exposed service on your router or computer and then escalate privileges using a 0day, known vulnerability, or misconfiguration on your part. If they had to use these vulnerabilities, they would use it to skip the privilege escalation stage and directly read memory.
Normally, a CPU executing code will eventually run into a fork in the road where the specific path it takes depends on some variable. If that variable takes some time to access (e.g. querying hardware peripherals or accessing memory that is not in the CPU cache), then the CPU will engage in an optimization technique dubbed speculative execution. This technique involves speculatively executing both possible paths in code, later discarding the path which it was not supposed to take. The Spectre vulnerabilities typically exploit the fact that this "discarding" is not perfect and still leaves some information behind that a side-channel attack can later discover.
* A few variants allow for a little bit more, such as covert side-channel communication and, in at least one example dubbed NetSpectre, attack certain theoretically vulnerable protocols to read memory over a network very, very slowly. Another variant allows setting read-only patches to read-write in certain, specific situations.


Receiving sensitive data uploaded on a Web server, and remotely accessing it without exposing it to theft

I'm not sure if I can understand your question correctly.

Mounting a directory with dm-crypted volume files by SSHFS and mounting those files to your local... Hmm... It sounds crazy to me and you are asking for a data corruption. Imagine what happen to the volume if you try to edit from 2 different network locations? Imagine what happened if your network breaks in the middle of "editing"?

You haven't written how many users you expect. You din't even mentioned, how large those tarballs are. If the files were small then I would suggest to keep them gpg-ed, and if you want to edit them, just download them, edit, upload.

I'm also not not sure, why you need to keep those data on the server. As you mentioned, all the data are encrypted and you are the only person who has the key. It seems to me the server is just an upload server and the only service it servers is the upload service. So, gpg every incoming tarball and sync it with your local where you can keep it on a single encrypted volume and edit them freely? Why you need the data on the server?


How secure is our privacy when using third party addons and extensions?

As soon as you install an add-on in your browser, you assume it to be fair. If you do not, you should not install it at first.

Using a free add-on without carefully analizing what it does, how it does it, and why the developper gives it for free is not really different that asking an unkown guy in the street to protect your house from (other) thieves and give him the keys. It may or not be efficient...

Now for the technical part. An add-on can be activated/de-activated at 2 possible levels: in the configuration options of the browser, or in its own configuration page (what is shown in question). When it is de-activated at the browser level, all is (well should be...(*)) fine: the browser does not call the add-on, so it cannot do anything; But when it is de-activated in its own configuration, it is still called by the browser so it can still monitor all the activity.

If an add-on is really malicious you cannot be totally sure of what exists in the system once it has be used once, even if you deactivate or even remove it. It has got the possibility to execute arbitrary code at user level. It should not have be able to process tasks requiring administrative priviledges (assuming you to not browse internet with an admin account), but could have changed user profile to run tasks at login. No decent plugin should do that, but if you have installed many plugins one could not be decent...

One security rules says:

  If an evil guy could persuade you to run his code on your machine, it is no longer (only) your machine.


What is the ideal technique to protect unauthorized redirects

If you only have one domain you can usually get away with simply prefixing a safe url (should have) handler://host/ (<--- the final slash is important).

redirect("https://example.com/"+$url);

Or you could whitelist all the known domain prefixes and compare the url to the whitelist (again safe url rules from above applies).

If you're planning on precalculating all the hashes of the redirect urls I presume you know all urls and you could just make a lookup table:

if ($url=="0000") {
  redirect("https://example.com");
} elseif ($url == "0001") {
  redirect("https://otherplace.com");
}

A whitelist will always be more effective than obscuring the redirect. Adding a prefix or suffix to the url before hashing can still be bruteforced just like a password hash can be, just consider the url a salt, but its unlikely that any attacker would go through that much effort. Open redirects by themselves are not significantly more dangerous than users clicking on links in email.


How does Software Defined Perimeter (SDP) protect against certains attack that happen in the browser?

SDP is a closed VPN solution replacing traditional VPN services like (MPLS, VPN concentrator, etc). The typical enterprise use case eliminates below pain points:

Leave their applications open to the Internet
Create an in-office VPN concentrator
Implement basic firewalling
Build their own VPN gateways
Pursue a traditional corporate VPN service

You may refer a commercial SDP solution at: https://www.perimeter81.com/software-defined-perimeter-enterprise

In my opinion, claim of getting rid of DDoS, XSS and CSRF are coming form the nature of not opening Enterprise applications to internet (users can connect through SDP with proper controls).

But this may not be applicable for services offered through internet (like eCommerce).


Latest Vulnerability Information for IT Security Research

Sure, plenty.

One of the most prominent is the Full Disclosure list, which was closed down in 2014 and then reborn.  You can find the past archives and subscription info at http://seclists.org/fulldisclosure/ .

Another good source of general information are Linux distros' security lists, which provide announcements of fixed vulnerabilities in their software.  A small selection:

Ubuntu
Debian
CentOS

MITRE provides some feeds of CVEs.


Preventing socket.join("room") client-side, listening for private room leaving

The client-side socket.io library does not have the ability to .join() a room.  That ability is only in the server-side library (because that's where the rooms are maintained) and thus the only place it can actually be processed.

So, the only way to join a room is to make your own message for a join request from client to server and process that message on the server on behalf of a given client which enables you to do any sort of checking you want before any client can join a particular room.  As such, you should be safe the way you're already doing it.

Similarly, there are only two ways that a client leaves a room.  The first is when you process your own message and call .leave() server-side so you can certainly monitor any time that happens since it's your own server-side code calling .leave().  The other way a client leaves a room is when the client disconnects and you can also monitor for disconnects in the server.  Like with .join(), the client cannot call .leave() directly so you don't have to worry about that.


Replace application's AppArmor profile without process restart

I found a function aa_replace_current_profile() that can replace current process profile. But I don't know how to replace the process you want.


IPTables default security rules for a gateway/router?

Right, so this is is a Hard Questiontm. Since all environments are different, it is very tricksome to provide a "One Size Fits All" ruleset that one can expect to just drop in. Any such configs, config snippets, recommendations, etc, must be fully grokked and tweaked to work in your environment. That being said, as discussed in the security.blogoverflow.com post (and in much greater detail), Base Rulesets in IPTables, this is a pretty basic set of sanity checks that I've built out over the years and have been recommending to people.

## Section 1
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp --icmp-type any -j ACCEPT
## Section 2
# Force SYN checks
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Drop all fragments
-A INPUT -f -j DROP
# Drop XMAS packets
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP
# Drop NULL packets
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP
## Section 3
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
###
# Insert your system specific rules here
###
## Section 4
-A INPUT -j LOG --log-level 7 --log-prefix "IPTABLES Dropped: "
-A INPUT -j DROP

Section 1

This is you pretty basic accepts. In general, you just want to allow ping and any localhost traffic or else things may not necessarily work as expected.

Section 2

This is a series of quick and dirty checks for known wonky packets that can cause problems. The only reason we put this second is for performance reasons.

Section 3

Here we allow all packets that are part of an existing session to come in. Most firewall admins would say to put this at the beginning of the config, performance reasons and all that. However, I would rather wonky packets be blocked even when part of an on-going session.

Section 4

Here is our log and default deny. The downside of putting the log message all the way down here, is that we won't get notified if any the wonky drops are triggered. We could move it up to the top, but that would either:

Make our config really messy
Overwhelm the logging engine

Really, it's your choice. As a generic recommendation, I opted for cleaner so that it would be easier to understand.


Why use any other password generation method when Diceware/EFF dictionary exists?

Should I create all my passwords with Diceware/EFF dictionary and
  only fallback to random characters if password policy forces me to
  include special characters and upper/lower case symbols?

As long as your systems support using passphrases you should use anything that is more comfortable for you. As long as it is secure enough. Please, when considering security, consider as many vectors as possible. It is easier to target users using social engineering to get their passphrase rather than password.

  2) Why in IT systems we still use randomly generated gibberish when we
  could use words?

IMHO, mostly because IT guys are technical guys, who get their knowledge on the matter from the proven (meaning old) sources. Passphrases are a relatively new thing, and most of the places where IT security is considered business-critical (banks, government, etc) have still active old systems (i.e. AS400) that do not support passphrases. It is mostly a matter of habit and trust.

I would advise you to consult NIST standards, various frameworks and so on to have a better understanding on requirements to passphrases.


What type of encryption/encoding is this? (Linux)

To quote Wikipedia:

  $id$salt$hashed", the printable form of a password hash as produced by
  crypt (C), where "$id" is the algorithm used.

  $1$ – MD5

So in your example $1$/avpfBJ1$x0z8w5UF9Iv./DR9E9Lid.

1 means it's an MD5 hash,

avpfBJ1 is the salt, and

x0z8w5UF9Iv./DR9E9Lid. is the password hash

You cannot decrypt a password hash; you can only brute-force it by hashing a large number of potential passwords and hoping you find a match.


I think you are correct that those issues are more related to code quality rather than security, and none of them are exploitable in any obvious way. I would not call them "vulnerabilities".

But vulnerabilities are born out of bugs, and bugs are born out of bad code quality. Bad error handling could lead to unexpected results - i.e. a bug - and if you are unlucky that could lead to vulnerabilities.

Here are some examples related to exception handling:

If you don't handle an exception at all, it could lead to the program crashing. This could be used for a denial of service attack - simply overflow the server with malicious requests that will crash it, and it will spend all it's time restarting instead of serving legitimate requests.
Unhandled exception might lead to disclosure of sensitive information, if error messages are passed on in HTTP responses (as pointed out by Rich Moss).
Overly broad catch statement that catch everything could lead to security critical exceptions being glossed over.

For real examples, check out this CVE list filtered on the word "exception" (as suggested by Ben Hocking).

The solution is to follow best prectices for exception handling. I will not cover that in detail here since that is more of a programming than a security issue.


Where should I store OAuth2 access tokens?

If the request to the 3rd party API is through your server, then store the access token in the database tied to the user, encrypted with a key that is stored as an environment variable. If the database is compromised, the tokens are safe. (Bonus, encrypt the tokens with a key that is generated and stored on the mobile app.)

If the request to the 3rd party API is directly from the mobile app, store the access token on the phone, encrypted with a unique key for each user stored in your server's database. Decentralized storage of sensitive information is more secure than centralized storage (compartmentalization). If the phone is stolen, it requires authentication to your server before the decryption key can be obtained. If your server is compromised, the tokens are not there.

I've not used JWT.


What is the difference between these SQLi queries?

There are some details which I would have wanted for a better understanding, but I'm assuming that you are trying to send malicious SQLi in a search parameter.

Let me use an example that you are searching for the term 'shoes'

The web request for that might be: www.example.com/search.php?tag=shoes

The SQL query for that request might use LIKE. I have used LIKE specifically because you are targetting search box. It would be a rare case or a very app-specific case where instead of LIKE, a direct comparison (=) is done.

SELECT * FROM table_name WHERE searchtext LIKE 'shoes' AND SOME_CONDITION

Now let's insert your given SQL queries:

1) ' or  1=1-- -> This will convert the query to SELECT * FROM table_name where searchtext LIKE '' or 1=1 . Rest of the query gets commented out.

2) ' or '1'='1 ->  This will convert the query to SELECT * from table_name where searchtext LIKE '' or '1'='1' AND SOME_CONDITION . This causes a different query to execute than above. Depending on the condition or the subquery the results will be altered.

3) ' or '1'='1-- -> This will convert the query to SELECT * from table_name where searchtext LIKE '' or '1'='1 . Its an INVALID QUERY. This query should not execute as the quotes are imbalanced. The application might be handling exceptions, hence you are able to see 0 results, otherwise, you would have seen SQL error on your web app.


There are a lot of ways to look at security questions, and rarely a "right" answer.

In this case, you might want to start by listing out what the basic goal(s) of the cryptosystem is/are; i.e., "what's the point?". From there, you can consider what is not being fulfilled if the hash doesn't match.

In this case, you're looking at a system that works by posting a hash along with the content. Why might this be desirable? What guarantees/claims are you no longer able to make if the hash doesn't match the content?

Hope that helps!


storage of client credential on OAuth2 server

I wouldn't consider this a major security issue as the values are limited to only your system's access to the third party sites.  It is less desirable, but the values can be easily invalidated without any bleeding in to other systems that access the same services.  It certainly doesn't hurt, and is even wise, to encrypt it, but you would have to encrypt it with a value found on the server anyway, so it only adds a mild amount of difficulty in gaining access to the keys.  You can't hash them like you would a password since they are just a token value that has no relation to any user input you ever see.

Depending on your use case, you could use the user's password for your system to encrypt the values (if you aren't using oAuth for your system's authentication), and you could only grab and hold the tokens while the user is logged in (if using oAuth for authentication), but that limits things like your ability to do any interactions while the user is offline, which may not be a viable constraint in your system.

Use of those keys should be restricted to your applications access to the third party systems and may well be limited to just your server's access to those systems as well, depending on how things are setup.

They are of pretty low value to an attacker.  It is a good idea to take what measures you can to protect them, but I wouldn't classify them as nearly as sensitive as a password (which is highly likely to be used elsewhere and gives direct access to the account).


How do I know which subkey GitHub is using for signing?

Github is not signing your commits at all -- all it does is verifying signatures. In fact, git is doing the signing work on your computer, relying on GnuPG for the cryptographic operations. GnuPG again will generally use the newest non-revoked key with signing capabilities unless you enforce something else, which will usually be your subkey.

When verifying commits or tags through git verify-[commit|tag], GnuPG will print the key ID used for signing, for example

gpg: Signature made Mon Jun 27 23:22:05 2016 CEST
gpg:                using RSA key 0x8E78E44DFB1B55E9
[snip]

This key ID references the key actually used for writing the signature, if a subkey was used, the ID is printed here. You verify by running gpg --list-keys [key-id] and having a look whether the key is listed as primary key or subkey.

For signing, usually the pinentry implementation of your choice will also print the key to be used when querying for the passphrase.


How exactly would SOPA-style DNS blocking threaten the security of the Internet?

The main security-related concerns raised so far are

attackers may use false infringement claims as a denial-of-service attack.
ISPs may start doing deep packet inspection on their customer's traffic, to look for infringing content.
it may interfere with the effectiveness of, or take-up of, DNSSEC.


You should go talk to your IT guys. It will probably be annoying and painful, but the alternative is likely worse (maybe not immediately, but eventually). From the sounds of it, the network probably has some form of MAC/port filtering, and the MAC address you're using is only able to receive an address at the specific physical port.

As someone who once was one of "the IT guys upstairs," if you did this on my network and I had to find out about it the hard way, I would have made an example of you. NIC cards are not expensive, and break all the time. If you just go and admit that you broke yours, they may give you a hard time, but that would probably be the end of it.


Reflective XSS in script codes with Content Type "text/javascript"

The question is, will any version of any browser, sniff a raw script code with Content-Type: text/javascript header set, given that X-Content-Type-Options: nosniff is not set.

For executing the script inside the browser it will not matter if the type is sniffed or not. If only the script itself is given to the browser, that is it is not embedded somehow into HTML, then the browser does not have a document where the script can run. That means the script will be displayed or downloaded but not executed within the context of an HTML document. If you use Internet Explorer it might also offer the script for execution, similar to other executable content. Some tests with IE11 show that it does not matter what the Content-Type is in this case, because either the data will be shown inline (text/plain, images) or it will be offered for download and maybe execute. If execution is offered seems to depend solely on the file extension and X-Content-Type-Options: nosniff seems to have no effect on this decision.

If the script is embedded or referenced from inside a HTML document the content-type mostly does not matter at all because the browser "knows" what the content must be (i.e. Javascript) and will usually ignore the Content-type set by the server anyway. Thus you can successfully deliver a Javascript file with a content-type of text/plain, application/octet-stream and even image/gif to most browsers. From the browsers I've checked a while ago only newer versions of Chrome will exclude some content-types, i.e. it is no longer possible to include script with a content-type of image/whatever into Chrome. It still works with other browsers.


Best practice for caching sensitive data

If the majority of your traffic is personalized data then you should use HTTPS and rely primarily on browser caches. Make use of this cache by setting Expire header and ETag.

Additionally, the Cache-Control: no-store advises browsers to not cache the data on a persistent storage, the data can only be cached on RAM. In effect, this is like session cache.


Who can certify RNG according NIST SP800-22?

This certification is typically done through FIPS certification.

The list of labs certified by NIST to perform FIPS certifications is here


Is there a server/website specific malware scanner?

If there is malware on your server, somebody put it there so you need to look at prevention first. :) It will also, often, be put in a place not referenced from elsewhere on the server, so simply spidering your site will not find it. Google will find it if/when somebody reports the exact URL, or it is linked from another compromised site.

I recommend taking another approach: host-based intrusion detection. To detect that somebody has put something on your server that shouldn't be there, periodically run a script (using cron) that checks that nothing under your document root has changed. If there have been changes, send yourself an alert by e-mail.

If you don't want to write your own script, there is software that can do it for you, as well. The original file integrity checker is called Tripwire, and there is an open source alternative called AIDE (on CentOS, run yum install aide as root). Some configuration required, but it can do just what you need.


For attackers looking to launch arp spoof on a target, does the attack have to happen in real time?

I think Yes, it has to be in real time.

As I understand the attack, it poisons the cache of arp entries in your OS using arp replies, and due to ARP protocol standards, it updates the cache of the OS immediately even if the entries is not expired.
After the attack is finished, the OS updates the ARP cache after multiple 'futile' requests using the poisoned cache.


The connection of the reverse shell originates at the attacked system, i.e. it is an outgoing connection. You ufw rules only restrict incoming connections but allow arbitrary outgoing connections - and thus allow the reverse shell.


Why default settings are generally weaker than optimal ones?

One reason is that older algorithms are likely to have wider support. Such defaults probably ensure that the software runs on a wide variety of platforms out of the box. The software itself might also be old.

It may be assumed by the developers that you will configure the software to meet your expectations after installation. It may be arguable that this is not an ideal assumption to make.

However, if the alternative is that the user must configure the software just to install it at all, then non-technical users may balk or may not be proficient enough to understand the installation/configuration process. Which  means that the software won't be installed or used properly, which is worse then being stuck with Triple-DES as the default cipher.


best operation mode for Rijndael-256 in PHP

For mode selection: anything other than ECB is safer. Do not worry too much ( have a look at https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation )

But for Rijndael-256 ...

http://php.net/manual/en/function.mcrypt-encrypt.php#117667

Rijndael-256 is NOT AES-256. Do not use Rijndael-256 or you may fail to decrypt (say, by OpenSSL).

https://en.wikipedia.org/wiki/Advanced_Encryption_Standard

  AES is a variant of Rijndael which has a fixed block size of 128 bits,
  and a key size of 128, 192, or 256 bits. By contrast, the Rijndael
  specification per se is specified with block and key sizes that may be
  any multiple of 32 bits, with a minimum of 128 and a maximum of 256
  bits.

And, mcrypt was DEPRECATED in PHP 7.1.0, and REMOVED in PHP 7.2.0, please consider to use OpenSSL or Sodium


A security audit wants encypted user/pass for login in asp.net - this seems pointless or is it not?

What auditor claims -- is an issue for unencrypted transport (plain HTTP, without HTTPS). In this case, authentication data is sent over the network in plaintext. This is where HTTPS comes to rescue. Like it was mentioned in comments, once the data reaches network module (in the case of HTTPS connection), the data will be encrypted and protected during transmission. And plaintext credentials on a client side are no longer an issue.

What I would add here is that entire web site should be covered by HTTPS and no page is loaded in plain HTTP. When authenticated, user receives authentication cookie which is sent to server with each page request. This is how server authenticates you. And if an attacker can grab these cookies, he will be able to impersonate the entity stored in these cookies. Even without having to possess user's login and password.

You may find recommendations for proper HTTPS usage and server security configuration to mitigate most potential flaws in your web application. For example, you may refer to this one: Transport Layer Protection Cheat Sheet.

p.s. and I agree with @joe that too many auditors have no idea on what they are talking about. In most cases they just blindly run their [vulnerability scanner?] software without digging and/or analyzing into what exactly it says.


Manually Validating Vulnerabilities from a Vulnerability Scan

Just because a vulnerability scanner identifies that a vulnerability exists in a package or library that you use doesn't mean that it's exploitable in your system. Even if it is exploitable, there may be controls in place that limit who can exploit it that are sufficient to reduce the risk.
Depending on the context, I'd recommend not blindly following the results of a vulnerability scanner. Instead, perform a risk assessment and prioritize deploying patches or fixing code based on the risk of the vulnerability to your code or organization. Taking on different user roles - public actor, end-user, administrator, operations engineer - and attempting to exploit the vulnerability to determine the impact on your system.


How to supply HTTP Basic Authentication details in OWASP ZAP proxy?

You need to add your app to a Context and then set up HTTP Authentication for it: https://github.com/zaproxy/zap-core-help/wiki/HelpStartConceptsAuthentication#httpntlm-authentication


Client bugs are bugs residing in client side programs used to connect or interact with the server:

  Client:  Either software that runs locally on a single computer or
  software that accesses shared resources provided by a server over a
  network.

  Server:  Computer that is configured to run software that awaits and
  fulfills requests from client processes that run on other computers.

The difference between client and server side code depends on where the code is executed. So either in the client program or in the server.

Your example can cover both server and client-side bugs:

Server doesn't offer MiTM prevention through (for instance) SSL
Client doesn't verify the certificate prior to setting up an encrypted tunnel

It can even be a combination of both server and client side code.


Requests like the ones you are seeing exist ubiquitously on the Internet. It's called "background radiation" and it's something that everyone with a public service has to deal with.

Don't worry about it. They are random probes looking for holes and if you have properly secured your site against this "background radiation", then you just weather it like everyone else. Assuming, of course, that you have secured your site against this type of threat.

If you are a startup, one of the investments you will have to make is to implement basic security, just like a new brick-and-mortar business would have to invest in locks and a security system. Contact a professional consultant to help you through that process.


TLS 1.0 & 1.1 support by browsers stops in March, what will happen if I keep using it?

The requests to those APIs will fail.

This is because browsers will try to do a handshake with the API server, and only accept servers who support TLS 1.2 or TLS 1.3. If those servers don't support either of those, the client will reject the connection.

As a result, you have several options on how to proceed now, each with varying pro's and con's.

Request the API providers to upgrade to TLS 1.2 or 1.3

This is the recommended approach, as it actually results in better security for every endpoint. The obvious downside is that you can't force the providers to do this, so you may have to look into alternatives.

Replace the API

If the providers of the API do not care about maintaining their service, then a valid strategy is to find someone who does. While the migration from one API to another is indeed a lot of work, the upside is that you work with a more stable API. This assumes that you can migrate to a different API. If the API you are consuming is the sole provider of the data or service you need, then you must find a different option.

Build a Proxy for the API

Simply put, your website provides a server that speaks TLS 1.2 and/or TLS 1.3, and simply relays all API requests and responses to the client. This may be a feasible solution, depending on the amount of clients requesting the API. It could also be used as a temporary workaround while the above mentioned API providers fix their TLS configuration.

Require users to use legacy browsers

This is an approach I am not a fan of, because it makes everybody less safe. However, in small environments, this could be a feasible quick-and-dirty (with the emphasis on dirty) workaround to keep things working one more day.


Generating a PIN from cryptographic bytes

Yes, you need at least 14 bits to generate a number between 0 and 9999.

In order to avoid bias, you can generate 14 bits of random data using a good source of randomness. If the result is <= 9999, then you can use it as your PIN. If the result is bigger, throw it away and try again.

  How much does this waste?

In the best possible case, your bits would align perfectly with your answer space, and you would not waste anything. You could generate a random value between 0 and 255 and all you had to do was to generate 8 random bits. Any result would be valid, assuming your random generator is good.

In the worst possible case, you would require a random number between 0 and 256, which means you need 9 bits, and thus have 512 possible values. In approximately 50% of these cases you would have to throw the result away.

In our example, our lower bound with 13 bits would only give us 8196 possible values, and our next possible target is 16384 possible values. Given that you want 10000 possible values, your possible space is more than one and a half times bigger than your target space.

But fear not, you are working with relatively small amounts of data. If you query 7 random bytes, you get 56 random bits, which means 4 "tries" to get a "good" value. Even if we would assume that you had a 50% chance (the worst case) to get a good value, in 4 tries you have a 93.75% chance of generating a good PIN. If you would be unlucky, you would have to query another 7 bytes, which would boost your chance to 99.6% to pick a good PIN.

  Cool! Can I have a demo?

function GeneratePIN()
{
    // The chance to fail after 1000 rounds is 7.5 * 10^-1203
    for(int round = 0; round < 1000; round++)
    {
        // We generate 7 random bytes, which would give us 4 "tries"
        ulong randomness = SecureRandom.GenerateBytes(7);

        // We can iterate this 4 times before our 7 bytes are exhausted
        for (int try = 0; try < 4; try++)
        {
            ushort possiblePIN = randomness & 0x3FFF; //0x3fff is 0011 1111 1111 1111 in binary, so 14 bits set to 1

            // If we succeed, we return the PIN. Else we try again
            if (possiblePIN < 10000)
            {
                return possiblePIN;
            }
            else
            {
                // =>> is the right shift, assign operator
                // This will shift randomness 14 bits to the right
                randomness =>> 14;
            }
        }

        // If we reached this part, we were unlucky and need to try again.
    }

    // If we reach this part, we flipped a coin 1000 times and always got heads.
    // Maybe buy a lottery ticket
    throw new Exception("Buy a lottery ticket!");
}


What does key, key pair and signature mean here?

It seems that Amazon is using this mechanism for authenticating requests to the CloudFront Servers. Read more here and here.

You generate a key pair using your Amazon account and sign certain URLs that point to private resourcesa and you distribute this signed URLs to the people you want to access your site. The parameters help identify the key that signed the URL(your private key) and the time until the URL can be accessed using this link.

This is how Amazon checks that you authorize the connection at that specific time.


I found out that arpspoof is a tool from the dsniff package. As long as you install it, then the arpspoof is ready to be used.

  The tool used here is called arpspoof and is distributed in the dsniff
  package.


What should I do when my boss asks me to fabricate audit log data?

Ask your boss to put the request in writing before you do it.

Make sure to keep a copy of the request in your own personal files. Ideally a paper copy at home, or maybe an email in your own personal email account.

You say that you already have a better job to go to, so just give your notice now and leave the company as soon as the notice period is up. Presumably you have a notice period? A contract of employment?

If you don't have a better job to go to, then find one as fast as you can.


How to find and ban some devices from my wifi using the command line?

nmap is a port scanning tool. It will allow you to find nodes which are routable/accessible in the ranges you specify. nmap will not reveal the network configuration settings on those hosts from a port scan.

If you are within the broadcast domain you could listen for traffic going outside of the network and analyse based on MAC addresses to see which endpoints in this network segment are going through the router.

Perhaps you are asking about why you are finding devices outside of your local subnet? That just means that those addresses are routable from your router, they may not be directly connected to your local router.

I will update my answer if you modify your question to clarify.


Why does P2P need port forwarding when behind NAT?

There are 2 main types of NAT, you can have one to one NAT (static NAT) where one internal IP address is translated to one external IP, and you have many to one NAT (hide NAT) where many IP addresses map to a single IP address. In many to one NAT when an internal host connects to an external host the IP information is put into session tables (I'm using this as a generic term to encompass all the tables a firewall may use in this case) so that the firewall knows what to do with return packets.

Things get a bit more complicated for sessions that are initiated by a host outside the firewall. With one to one NAT it's very simple as there's only one place the packet can go, but when there are many hosts behind a single IP address the routing device has no indicator of where an incoming packet should be directed. Port forwarding is one way to solve this problem, a port forward rule will allow the device to do the destination address translation and forward the packet accordingly.

Port translation is not often used as a solution in enterprise networks although I can think of some exceptions to that. Enterprises usually have a block of publicly routeable IPs, so they will set up a one to one NAT when an internal host requires access from an external IP (or just assign the box an external IP in the first place). Port translation is much more of a home broadband solution where your router only has one IP address to use. When you fire up your p2p software externally initiated connections won't be able to reach it unless it there's a port forwarding setup, either manually done but more likely UPnP, where the application tells the router what the port forwarding setup should be.


Clean and cheap protection for user registration HTTP requests?

I am struggling to imagine how this provides any protection against ip-spoofing. Regardless IP-spoofing on a TCP connection is hard to achieve - I would recommend you ignore it for now.

In terms of DOS protection, I would urge caution. The more sophisticated your measures for protection, the more they become a bottleneck and hence exploitable by DOS.

  I thought to add a temporary random token to POST parameters that is stored also on my server for one or two seconds

Sounds rather expensive to me. You really want to minimise the amount of information you are capturing/attempting to store about potential DOS requests.

One solution is to put the storage cost back on the client: Create a cookie on the browser in an earlier page containing serverside encrypted values indicating some attributes about the client (such as the IP address or ASN, browser...) and a millisecond level timestamp using javascript and validate it in the POST request.

Note that you need to think about how you would validate an IP address which can span more than one session.

Dropping the cookie and using javascript validates that the client is a browser (or a fairly sophisticated facsimile) which has visited other pages on your site. A short interval between the timestamp generation and the cookie being presented would indicate a scripted attack.

  rate-limit protection techniques using nginx and at a lower level using iptables

I will assume that you have ensured that these do not have a capacity impact and you have resized your conntrack table.


How to sign & timestamp log or zip files?

If I understand what you are asking, it seems to me you are looking for a File Integrity Monitoring solution. Are you familiar with FIMs, or have you researched them? Do you think that fits what you are looking for?

Not sure what budget you are working with, but Tripwire is popular FIM vendor.


If you go straight to the source, there is a column for notes. I don't know if there is a collected works.
Notes 1 and 3 in Oracle security advisories for Java SE is for this.

1. [...] This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data
to the APIs.
3. This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start
applications or Untrusted Java applets, such as through a web service.

It's quite difficult to explain the difference concisely to the intended audience. Previously advisories used the terms "client" and "server". Note 2 is only for deployments that "load and run untrusted code", which is to say where the SecurityManager is used as intended, such as RMI.
I don't think many people get much out of security advisories. I'm sure it's read mostly to give the impression that they are making an informed decision (they aren't).
Presumably a modularised Java SE 9+ deployment could skip updates in areas that it definite does not use.
Reduce the attack surface. Disable Java Serialization (narrow whitelist if you absolute must). Keep patched.


How can i prevent my phone from spying through sms

without knowing how exactly the message initiates the attack its hard to say how to protect your self against it.

if we assume that it has to first touch your os for anything to happen then what you could do is create a small android application (simple one) which simply runs in the background as a service and isolates the message from you/the rest of the system unless it follows certain rules (i.e its from someone you know/approve)

and then if it passes the tests you set out it will forward the message onto your system and have it as a normal message.

As I said this is a difficult question to answer as smurf is a government application, I would need to know at what point the sms triggers a take over. as soon as it gets to the phone? as soon as it is read? as soon as it gets to the official inbox? its hard to say.


Security risk of using virtual hosts for public and internal sites

Yes, that's possible.  In fact, if the internal name is in (global) DNS, they can request the internal site by name.

However, you can still do what you're trying to do and be (mostly) secure.  You don't say what version of Apache you're running, and things changed slightly for version 2.3.  In Apache 2.3 or 2.4, you can use mod_authz_host to restrict the internal server to specific IP addresses, namely those on your internal network.  So, you could do something like this:

Require ip 10.1
Require ip 10.2 172.20 192.168.2

Depending on the complexity of the local network, one Require ip may be enough.  The full documentation is here: http://httpd.apache.org/docs/current/mod/mod_authz_host.html

For versions prior to Apache 2.3, you would use mod_access (http://www.auburn.edu/docs/apache/mod/mod_access.html) which works slightly differently but can accomplish the same thing.

You are still running the external and internal sites on the same instance of Apache, so an error in Apache itself could potentially expose internal pages to the outside.  So could errors in setting up the access controls or errors in placing files.  Access via VPN will present an address from the VPN concentrator, so those will look like 'internal' requests, which is probably good.  Finally, requests from a proxy server will present the address of the proxy.  That probably doesn't apply; there's a note in the apache docs about this.

You can increase security somewhat by using a server with two network interfaces and assigning each virtual host to its own interface.  You'd use an internal (RFC 1918) IP address to the internal virtual server.  For best security, you need two physical machines, one on the internal network, with an internal address, and one in the DMZ with a registered (or port-forwarded) address.

Finally, you could require authentication (login) for the internal server.  Whether this is practical or necessary. depends upon the number of people who will be using the internal server and how sensitive it is.


Is WhatsApp web able to read end to end encrypted messages?

1) Would say "NO" if they really implemented full end to end encryption..

2) Man in the middle attack scenario still exists

3) I really doubt the end to end encryption for images and videos or files,,. Considering below cases
  a) sending group messages
  b) getting content after a while even if the sender deleted the original files..


I see a couple problems here.

There's no IV

That means that if you encrypt two identical messages with the same key, the cyphertext is the same. If even part of the message is the same, it's possible to determine the content of the other messages, and even the key. Read about crib-dragging and you will see why.

As strong as SHA-256

Not really. It's as strong as the key. You are using a numeric key, but how long? It's 4 bytes long, 16 bytes long, 512 bytes long? That makes all the difference.

Numeric key and SHA-256

A numeric, auto-incrementing key is bad. SHA-256 bruteforcing rigs are plentiful, usually they are sold as Bitcoin Miners. They are cheap, they are efficient, and very, very powerful. Use one to generate Terahashes per second, apply your very, very fast XOR calculation, calculate the entropy of the message, and an attacker can bruteforce your secret message in minutes, maybe less.

XOR encryption with truly random numbers

They are not random, they are deterministic. Bruteforce the first block, and all your data is broken. If the first bytes of the message are deterministic (like a request header, or file type header, or Greetings dear user  kind of message), and attacker can use the crib-dragging attack to infer part of the hash and feed it to the bruteforcer.

Vulnerable to Know Plaintext Attack

If any attacker knows the plaintext-cyphertext pair, he knows the XOR-key, because plaintext XOR cyphertext = KEY. That information goes to the bruteforcer and you know what happens.

Vulnerable to frequency analysis

256 bytes of data is enough to reconstruct part of the message using frequency analysis. Reconstructing the rest of the first 256 bytes is trivial, and results on a pair plaintext-cyphertext. This enables the know plaintext attack on the first 256 bytes, allowing the XOR-key to be discovered and bruteforced.

I know you are trying to learn, but trying to learn crypto by doing it is like making a gun by trial and error. You will shot yourself in the foot, or head. Wikipedia have a nice article on symmetric encryption, with a list of algorithms, the principles behind them, and the shortcomings.


How does sign-in with Social Login work for a 3rd party relying party

I would suggest that you start with some of Dominick Baier's courses on Pluralsight.  In particular, you might want to start with his Introduction to OAuth2, OpenID Connect, and JSON Web Tokens (JWT).

If you are writing services that require the user to login every time to use, then I don't think you want to use OAuth.  If you are writing some kind of mobile or service app which needs to later login to these services on the user's behalf, then yes, you should consider OAuth.  As Dominick Baier explains, the OAuth spec is a bit of a mess, and OpenID Connect is even more so.

I would suggest you do the following:

Use a "Federated Secure Token Service (STS)".  The purpose of the Federated STS is to issue your application with authentication tokens which contain "claims" that your application understands.  For example, these claims could contain the user's email address, full name, etc. -- whatever you specify.  When the user tries to access your services, they are re-directed to this "Federated STS" which offers the user choices at to how they want to login (Facebook, Google, Live, LinkedIn, etc.).  The user then logs in, the Federated STS receives the authentication token from Facebook or LinkedIn or whatever, transforms the token and its claims into a format your app understands, and your app then consumes this nicely made authentication token.  There are a number of Federated STS services, including Azure ACS, Azure Active Directory, etc.
You probably want the token to be a JSON Web Token (JWT).  In the configuration of the Federated Identity Provider, you specify how you want it to "transform" claims into a format your application can understand.  For example, if you application wants a "Full Name" field, and Facebook returns a "First Name" and "Last Name" field, you can instruct the Federated STS to convert the Facebook information into a "Full Name" field.
Here is an example of what a JWT looks like:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}
but you can choose to have whatever fields you want.
After the client logs in, is authenticated, and redirected back to your API, the API will typically receive an HTTP header with the JWT token, although there are other schemes.
You can configure the Federated STS so that it will also return the name of the Identity Provider the user chose (Facebook, LinkedIn, etc.)
I don't completely understand your question about the "client and user-agent" not running, but you might want to look at OAuth2 and "refresh tokens" for this.
Yes, it is very important to authenticate the client.
Rather than extend the API to handle different kinds of authentication schemes and tokens, I think you should use the scheme I advocate above to offload all the authentication to a "Federated Identity Provider/STS" so that your code is not tightly coupled to authentication, and so that you can add new "Identity Providers" and "claims transformations" to the Federated STS in the future without any code changes.


Design a webapp that uses OAuth, but with tokens that can't be used by the operator?

Since the granularity of scope authorized by the StackOverflow API stops at 'write' level, it's not possible to restrict authorized privileges to only voting.

The users will simply have to trust you.  They can always revoke their permission via the online app, so they could limit any damage you may do (or someone who compromises currently active tokens).

If you wanted to improve your security against attackers, you could drop tokens which haven't been used in a while (even if they're not expired) to limit any damage.  The only other thing i can think of is to properly implement the secure connections when dealing with tokens.


what is the appropriate data integrity check control for the data at rest?

In some cases, a modified ciphertext may trigger a padding error upon decryption.  However, this will not always be the case, therefore authentication is needed in addition to encryption.
Some modern modes of AES encryption (such as AES-GCM) combine authentication with encryption.  Other modes of AES (such as AES-CBC) do not include authentication, so an authentication function (such as HMAC) is often used in conjunction with these modes.
See Why do you need message authentication in addition to encryption? for more information on this subject.


Tools and methodologies to share pentest and/or source code analysis results

HP AMP and HP Fortify 360. HoneyApps Conduit. Denim Group Vulnerability Manager, Veracode, Aspect Security ARMS.

Atlassian Crucible, Friendpaste, SyntaxHighlighter, Smartbear Software CodeCollaborator


Is buffer overflow the only way to take control of stack pointer?

In a word, no.

Buffer overflows can occur on both the stack and the heap. Stack-based ones are the classic target, since the saved stack pointer and return pointer are part of the stack frame and if you can overwrite either you can usually control the instruction pointer (IP) as soon as the function returns. However, there are ways to turn almost many kinds of memory corruption into arbitrary code execution.

A partial list of ways that are specific to buffer overflows:

Tamper with heap memory allocation (i.e. malloc) metadata, which is stored on the heap itself and usually near the allocated buffer. When the buffer is freed, a value might incorrectly be written to a user-controlled address (such as the return pointer, or a function pointer variable, or...). This one is heap-specific.
Overflow into a neighboring data structure that the attacker shouldn't be able to control, and change it in a way that gives code execution (such as by changing a function pointer that is later called, or changing an object's class reference so that it treats attacker-controlled data as its vtable, or changing the value of a pointer that is about to be written to). This can be done on both the stack and the heap.
Change a neighboring variable so that code flows down a different path than it should (e.g. bypassing an authorization check and granting access when it shouldn't). You don't always need complete control over the IP to get the desired result; sometimes just getting the program to take the wrong branch is good enough!

A partial list of non-buffer-overflow-based ways to control the IP:

Trigger a double-free, by passing data that causes the program to try calling free (or delete or whatever) on the same non-NULL address more than once (without re-allocating in between). This corrupts the heap metadata in predictable ways and can be used similarly to the first bullet above.
Trigger a use-after-free, by providing data that results in the program taking a code path where it frees a buffer, allocates a new object in its place, but also continues using the original pointer (to the old object type). Treating a pointer to an object of one type as though it's a different type is often exploitable, for example by changing a field that is a harmless, user-controllable int, but has the same address (in the other type) as a non-user-controllable function pointer.
Format string vulnerability, where a function of the printf or scanf family is used but the format string is at least partly under attacker control, because the attacker can use the %n format specifier to treat an arbitrary "word" along the stack as a pointer and write an attacker-controlled value to the address it "points to".

Memory corruption in managed-language environments (such as .NET, Java, Python, JS, etc.) is supposed to never happen (unless the managed code calls some native code) - that is, it's not supposed to be possible to write this class of bug in those environments - but managed-code runtimes are themselves written in native code, and native code sometimes has memory corruption bugs. The existence of such memory corruption bugs in those managed runtimes is often a serious security vulnerability, because a lot of them are used for running code from untrusted sources. For example, there have been many use-after-free bugs found in various browsers' JS runtimes, which can be exploited by a maliciously-crafted script to break out of the browser's JS sandbox and run code with the browser's privileges (this is a large part of why browsers are now sandboxed by the OS).


How safe are Wi-Fi Hotspots? Because WPA 2 is compromised, is there any other security protocol for Wi-Fi?

EDIT/UPDATE 2017-10-17: This answer does not account for KRACK. That's an attack on both WPA2-PSK and WPA2-Enterprise. There's ways to detect and mitigate it, but they're not covered here.

You need to make a difference here. There's multiple things to consider. Also "WPA2" isn't precise enough – there's WPA2-PSK (pre-shared key), and WPA2-Enterprise (which relies on an external auth server)

1. The attacker wants to gain access to traffic or network, but is not in possession of the credentials to enter

Well, bad luck. WPA2, both PSK and Enterprise protect well against that, unless the credentials are easy to guess. And that's not a "brokenness" on part of the system – if you used your user name as login to a website, you really can't blame the website for being "easy to crack".

So, in this respect, WPA2 is utterly secure (as long as you don't use WPS, but your question is about hotspots, so that's pretty surely not the case).

2. The attacker is already part of the network and now wants to read other user's traffic

That's an especially relevant attack scenario for hotspots – getting access to the network might be as simple as buying a cup of coffee in cash.

So. Let's make a difference here:

2.1. Hotspot uses WPA2-Enterprise

You log on to the hotspot, proving (securely) that you know the credentials. The access point checks that in cooperation with an authentication server (802.1x). The authentication server generates a secret that is cryptographically secure enough to base your communication with the Access Point on. Every user gets a different key for encrypting their traffic. No user can spy on other users.

WPA2-enterprise is not "broken" in any sense of the word.

2.2. Hotspot uses WPA2-PSK

You log onto the access point, proving that you know the PSK. The access point generates, in cooperation with you, a secret key with which you encrypt and decrypt traffic between you and the hotspot.

Other users do the same: prove that they know (the same) PSK, then generate a secret for their traffic crypto.

So, in a first look at the system, this is just as secure as WPA2-Enterprise.

HOWEVER: Due to weaknesses in the way the user-AP secret keys are generated, it's very easy for someone who already has one of these keys (which being logged on to the cafe's AP guarantees) and knows the PSK (which every user of your favourite coffee shop does) to recover the secret user-AP key of someone else by observing but a couple packets, totally passive.

That is a serious design flaw.

Hence, WPA2-PSK is "broken" in the sense that it doesn't protect users of a WiFi network against spying by other legitimate users of the same network. @Josef and I aren't in full agreement whether that is "by design" or really "brokenness".

In any case, what you should take away from this is: whenever you're on a WiFi that uses the same key for everyone, your traffic can be read by everyone else on the network.

Is there any other security protocol for Wi-Fi which is not compromised?

Use WPA2-Enterprise. You will need to set up a 802.1x server (typically, radius or something equivalent), and that can be a hassle, but if you own an Access Point and want to provide secure access to everyone, that's your only choice. And it's not that complicated, at all.

If you're just a user of a wifi, old saying says:

Trust no-one else's infrastructure. Use encryption.

In other words, if you're on a network where you can't trust other users, you might as well not trust the Access Point, which has the job of deciphering your WiFi traffic...

Use a VPN whenever you're on someone else's network. That's standard etiquette.


Is overwriting the entire hard disk (e.g. with `dd`) sufficient to ensure that ransomware has been removed?

Doing this, you wiped all the disk, turning all the data to zero (hopefully).

It does not mean it is safe enough:

Some kind of malware can reside in hardware (barely possible, but still a chance).
Some other can be placed on the MBR, so i would suggest you to wipe it too. Use: dd if=/dev/zero of=/dev/sda bs=512 count=1 (it also deletes the partition table). But you already did.
And stay sure every device attached to this isolated computer is clean too.

Hope this will help.


Is it possible to store / record HTTPS client auth traffic as a signed document?

No.

There is an even simpler scenario for this question, without the client certificate.

You ask, given pcapng / tcpdump / wireshark file of the entire communication session between client and server and an SSLKEYLOGFILE dump in NSS Key Log format so you could decrypt the stored traffic, is that proof that the server sent whatever the file says the server sent?

And the answer is no, it is not.

TLS does not provide non-repudiation. The signature is proof that you communicated with the other party, but it is not proof of when the communication took place (because gmt_unix_time is deprecated) and it is not proof of what was communicated, only that the communication took place (possibly without any application data being sent).

After the handshake, both sides have the same symmetric keys for both sides. Both sides can generate a transcript that shows the other side sent, encrypted and authenticated with the expected keys, any data. There is no way to know whether that is true or not.

To achieve non-repudiation, you would need to add a digital signature at the end of the connection, signing a hash of the entire connection until the disconnect message was received. But there is no such feature in TLS.

Alternatively, you would need your friendly local sigint intelligence agency to provide a packet capture file that they certify is authentic, and one of the sides of the communication to provide SSLKEYLOGFILE dump, and then you would know that some packets were really sent in that direction and the cleartext data.


How to prevent CSRF attacks on a REST API when using Windows Authentication

You need to make sure that your token endpoint has an access control origin policy, otherwise the attacker could request your xsrf token and then use it to modify the state.

As long as you are assigning a token to a request from a secure origin, then validating that token in your post handler, you should be ok.


Source for up-to-date GPU/ASIC hash performance?

In June 2016, Jeremi M. Gosney (the guy behind sagitta HPC) published the results obtained with their top-end password cracker, running Hashcat v3.00-beta: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40

This list contains all hashing functions implemented by Hashcat which, unfortunately, doesn't support Argon2i yet.

Regarding SHA256, the results are:

Speed.Dev.#1.:  2865.2 MH/s (96.18ms)
Speed.Dev.#2.:  2839.8 MH/s (96.65ms)
Speed.Dev.#3.:  2879.5 MH/s (97.14ms)
Speed.Dev.#4.:  2870.6 MH/s (96.32ms)
Speed.Dev.#5.:  2894.2 MH/s (96.64ms)
Speed.Dev.#6.:  2857.7 MH/s (96.78ms)
Speed.Dev.#7.:  2899.3 MH/s (96.46ms)
Speed.Dev.#8.:  2905.7 MH/s (96.26ms)
Speed.Dev.#*.: 23012.1 MH/s


W3af and automated vulnerability scanners vs manual testing

Manual testing:

Slow;
Humans can forget some important tests;
Complex, sophisticated and creative testing.

Automated testing:

Fast;
Tests a lot (thousands) of vulnerabilities (never forget a test);
Easily repeatable after remediation;
"Cake Recipe" (will just test what it was designed to test).

Based on the above points, we can say that each type of testing have its own positives and negatives sides.

  Are they able to find all vulnerabilities from OWASP top 10 such as
  reflected xss, persistent xss, sqli, lfi/rfi, and unrestricted file
  upload?

A lot of Web Security Scanners were designed to find all the above types of vulnerabilities, but nothing can guarantee that they will find all instances of the above vulnerabilities.

  Or will some vulnerabilities fall through the cracks and remain
  undiscovered?

Some vulnerabilities can fall through the cracks, no tool is perfect.