Easy explanation of SSL client certificates for a developer

Edit: I realise that this may not be clear from the answer below... but from the point of view of your application, it doesn't really make any difference whether you run the PKI/CA yourself or whether you use one or more third-party CAs. Even if you choose to run your own PKI, you really don't want to code it yourself - so you'd use one of the existing ones, which would be logically separate from the application, and any interaction with the CA would be via the usual protocols. End of edit

  Should I really be operating a PKI and issuing the certs myself?

As a general rule, unless you already know how to run a PKI, you shouldn't be doing it. It's a lot more complicated than you'd think, and a lot more ways that things can go wrong. Even companies that do PKI as their core business get it wrong sometimes; see Diginotar who had their certificate infrastructure hacked and eventually went bankrupt.

Allowing third-party certificates, especially by multiple CAs, has its own pitfalls. I have a smartcard that contains my electronic ID that I use to access my bank and several government sites. But I might also have a "soft" certificate that I use to access other things. If your site would accept both those certificate authorities, would you have any way to know that those two certificates refer to the same person (or user)? Would you want to have one user per certificate, or would you want one user to be able to use more than one certificate? What happens when a certificate expires - how would you know that my new certificate still refers to me? These questions need to be considered carefully when you design your applications and chains of trust.

  Is there a way of making them behave just like SSH keys, the user
  presents any key during signup and that key is bound to the account?

This is just a Small Matter Of Programming... (In other words, not so small, but not impossible.) You'd probably want some way for the user to add/remove certificates, too.

  About verifying them in my app, most documentation I've found makes
  the web server check the certs against a CA (my own CA in this case,
  which brings us back to the PKI problem) and setting an environment
  variable if the cert is trusted ... that wouldn't work in my case as
  I'd like to get rid of the CA and have the clients provide their own
  certs, so based on the fact that I can't rely on checking them against
  a CA, what can I check them against? Do client certs have the
  equivalent of the SSH public key I can just store in my DB and check
  against that?

You wouldn't save the entire certificate, you'd just save enough information that you can verify the certificate the next time the user presents it. This would usually be the certificate serial number, the CN and the issuing CA. You might also want to store the expiry date, so that you can remind users to renew their certificates before they expire. (This could of course be done when you check their certificates at login time, but it might be wise to store the data so you can email a reminder in case they don't login during the time they would have got the warning.)

Even when a certificate is issued by a third-party CA, the certificate will contain information about how you can verify its validity. This will usually be by OCSP (Online Certificate Status Protocol), which is a real-time check against the issuing CA's database. There's also CRL, a Certificate Revocation List, which contains information on which certificates are revoked by the CA. This is not real-time; the CRL will be re-issued at intervals.

  Finally, how would a new customer go about signing up to my website;
  he's asked to present a cert and he doesn't have any, how does he
  generate one?

If you choose to use third-party CAs, you should give them a link to one or more of the CAs you trust.

If you run your own CA, you'd give them a link to that CA, which would have to be configured to allow (previously) anonymous users, as well as existing users, to request a new certificate.

Finally, if you want to have a look at setting up a PKI, you could try out EJBCA, an open-source CA/VA. It will give you a basic idea of the complexities involved.


802.11w protected management frames - Wi-Fi

I read that this MIC is derived from the PSK (e.g. WPA2 key). Does
  this mean that these frames are still spoofable from inside the
  network (i.e. if you own the PSK)? Or does it defend against insider
  de-auth attacks as well?

If you have the AP's MAC address, SSID and WiFi password then you have everything you need to impersonate an AP running 802.11w anyway (how else are the clients going to know the difference between real and fake?). So while a user on the LAN alone (i.e. they have plugged themselves into a nearby networking switch) may not be able to spoof your AP without having the PSK it does not defend against users who are trusted on the wireless (and have the ability to recover the wireless password) sending de-auths to other clients.

  does not defend against most other attacks such as RF jamming, evil
  twin and rogue APs, but it does defend against misassociation attacks
  and de-auth attacks. Is it still useful for this reason?

Put simply 802.11w just signs the integrity of management frame packets as coming from the AP. Previously only a MAC spoof of the AP was all it took to pretend to be the router asking you to leave the network. So once you know this, 802.11w will obviously not guard against jamming caused by a splatter of nonsense in the RF (because 802.11w is not above the laws of physics) or another AP with the same SSID and PSK of a stronger signal (because then the clients will just join that instead anyway).

802.11w put simply is there to stop the man/woman in the street telling your devices to disassociate from the WiFi network (in the hope of capturing your authentication data to then bruteforce the PSK), that is who it's protecting against. 802.11w is NOT there to defend against someone determined who is already on the inside from impersonating your access points or who can just jam every 2.4Ghz frame on those channels in that area.

If your clients support 802.11w (and they support it well!) and your Cisco AP isn't running a buggy 802.11w implementation itself, then why not turn it on :-)?

  I have not heard much about Protected Management Frames and cannot really find much information about them from after 2009. Are they widely used? In public and private networks?

"802.11w is an IEEE standard based on Cisco’s Management Frame Protection(MFP), a feature that was first supported on autonomous access points in release 12.3(8)JA in 2006 and in the unified release 4.0.155.5 in 2008. 802.11w isn’t a new standard. IEEE ratified the 802.11w standard in 2009, however the adoption has been slow to date, but that is expected to change with Windows 8."

Windows did not really support it until Windows 8 and up (though I speculate given it's the driver that supports it, probably any new driver does and very likely 802.11ac supporting ones).

There's also some horrendously buggy wireless implementations that claim to support message signing (because they have just repeated back the AP saying it supported it) but then refuse to sign even a single packet with it. See also https://supportforums.cisco.com/discussion/12543141/wap371-firmware-v1202-wireless-client-incompatibility which also links off to a list of bad clients I have discovered (I don't have the rep points on this site to post more than 2 links yet).

I also found this online (unable to link to source due to reputation limitation):

"The IEEE 802.11w amendment added this functionality to the 802.11 standard and since July 1st 2014, the Wi-Fi Alliance (WFA) made the support of Protected Management Frames (PMF) mandatory to pass 802.11ac or Passpoint aka HotSpot2.0 R2 interoperability certification. So we will see a much greater adoption of this feature in the near future."

The standard is probably the best guide to read (http://standards.ieee.org/getieee802/download/802.11w-2009.pdf).

802.11w uses AES in CMAC mode and AES was added as part of WPA2, so WPA2 support looks required to enable it.

Also to help your research, Cisco refer to it as Management Frame Protection (MFP) but the standard refers to it as Protected Management Frames (PMF). "For reference, 802.11w was rolled up in the 802.11-2012 maintenance release of the 802.11 standard."


Is there a way to prevent someone from making his own client app for my webservice?

This would be impossible. It is fundamental for your app to contain all the  instructions necessary to use your API. Anyone with enough skill and time will be able to extract these secrets and create their own client.


LastPass - maintaining security on foreign devices

There's a second option also. LastPass have their app for mobile devices.

You can access your password vault by logging into your account on your mobile device, search for your password and type it manually. Some devices also allow to use fingerprint scanner to speed up this process. It is a better option in my opinion than accessing a website on a foreign computer that may be compromised.


Is there any other way through which an attacker can obtain user data from HTTP response except MITM and CORS attack?

... except MITM and CORS attack

I'm not sure what CORS attack you refer to but my guess is you mean attacks possible by an overly broad (permissive) CORS setup.

Apart from these the attacker might get access to the HTTP response if he can execute code at the client with the Origin of the target domain (or whatever CORS allows additionally). This can be done for example through XSS (cross-site scripting) but also by compromising any server from which the client includes script into the original page (like advertisement or tracking server) and modifying the script served by this server.

And then there are WebSockets which don't have any same-origin policy. Unless the WebSocket server of the specific domain explicitly and properly checks the Origin an attacker could simply create a WebSocket connection to the specific domain within a JavaScript on his own site, make the victim visit the site and then can communicate with the WebSocket server with the existing authentication information (like session cookie) of the client - see Cross-Site WebSocket Hijacking (CSWSH).


How does Android filesystem encryption work?

Android uses dm-crypt for disk encryption, and it is available since Android 3.

And as you would know dm-crypt works at block device layer.
So storage like YAFFS which works directly at nand flash chip level would not allow you to encrypt. But all other storage (which can be read block by block) can be encrypted.

Yes, both device and external sd cards can be protected.

Reference: https://source.android.com/devices/tech/security/encryption/


NMAP shows multiple outputs in OS detection

It can be something in front of that host, but sometimes Nmap can give you near-matches possibilities, which I doubt that's the case in your situation.

  When  Nmap is unable to detect a perfect OS match, it sometimes
       offers up near-matches as possibilities.

If you know that host, then check which services are running on the targeted machine.

nmap -sV ...

If the result doesn't match with host that you are familiar with, then it's obvious that OS detection came from another host.


Does the md5 (or any hash for that matter) of a string include the null terminator?

I think this depends more on the implementation of the hashing algorithm than their ability to hash a null-terminated string including the null-terminator itself.

A few of such occurances of hash function implementations were observed in TrouSerS (version 0.2 built on Trousers Software Stack 1.1, or earlier) used in Gentoo Linux as one of the crypto libraries in its software stack and in TrustedJava (before jTSS 0.4a), and in IBM Client Security Software, both implementations included null-terminators on password popup dialog entries (null-terminated strings including null-terminators themselves).

Similarly, you can UTF-16 encode plaintext before passing it to the hashing function, causing every other character in the input to be procesed as 0x00 or null character for non-extended characters by the function that processes input as plain ASCII. Depending on the hashing algorithm itself, its intended purpose, and the input length, this could be either beneficial (say, to password hash security, e.g. hashcat has some problems with these), or cause decreased password entropy, if that causes the hashing algorithm to ignore parts of the input (e.g. bcrypt, a cryptographic key stretching hash algorithm implementation based on Blowfish symmetric block cipher, limits plaintext to 72, 55, or 51 characters - depending on who you ask - and ignores the rest).

As for a general advice whether to include null-terminators in inputs to your hashing algorithms, I have none and you should be a bit more specific about the intended use you're hashing data for (are we talking of cryptographic hashing for password storage or HMAC here?), and will vary greatly depending on your specific needs and chosen hashing algorithm.


Firstly please take a look at the suggested answer How to encypt sensitive data in database of a web app? (as per the helpful comment by @mentallurg

From a defence in depth approach, it absolutely makes sense to encrypt values on the database, as well it is worth taking measures to limit and contain breaches, such as ensuring your application is resilient to SQL injection, its DB connection is done with an unprivileged account (ideally multiple depending on the role and task) that can access only a subset of data on the database. Then the database server should be segregated from the remaining network. The database service should be running under unprivileged user permissions and have system command execution disabled.

As to how you should manage encryption and keys, there's several good solutions (as per the recommended question/answer), but be very very careful, as there's many times more bad/ineffective/insecure solutions.


What protects a JWT from being hijacked and used to pose as the original user?

JWT  are only an encapsulation of information into a string with the ability to encrypt these information and detect tampering. JWT by themselves don't protect against cookie theft or misuse done with sniffing, XSS, CSRF, browser extensions or similar.

This means you still need to employ the usual methods to protect the token or cookie against misuse, i.e. use http-only cookies to protect against XSS, use TLS to protect against sniffing, use CSRF tokens or other techniques to protect against CSRF etc. And you might include some information in the protected token which make misuse harder, like a fingerprint of the browser, source IP of the user etc  - see OWASP: Binding the Session ID to Other User Properties. Of course you need to verify these information each time the cookie is used for authorization.


Security disadvantages of sending a password with GET?

No confidential data should ever be sent via GET.

The data may be leaked or stored by:

referers if you link to a different page after a login
your server logs which is an issue if these logs are ever available, for example via LFI, wrong server configurations, backups, etc.
browser histories which is an issue if multiple people use the same browser - eg in companies or in public libraries -, or even by other websites if history sniffing is an option.
proxy servers that can decrypt the requests
users sharing links

The CWE for this issue would be CWE-598.


Thinkpad X1 Yoga refusing to restart. Was this a regular Windows failure or due to a hack?

Many users tend to blame computer failure on getting "hacked", I'm glad that you are open to the possibility of it being something else. You very well could have been hacked.

From experience, when I have a problem like that, it is a botched or corrupted update. I had a little bit of connection trouble during an update, and somehow (maybe it didn't verify the md5) my computer just died. I did a fresh install, and everything worked again.

Considering you have bit locker, I would decrypt everything, then use another os to try to rescue all the files, then do a fresh install and put everything back.

I hope this answers your question, if not please tell me in the comments so I can fix my answer.


How can I apply message digest to the application so that user can validate the accuracy and completeness of the software

You should provide the user with a message digest (ex - sha256) so that user can validate the accuracy and completeness of software. Digests are designed in a way that even a single bit flip in your application will result in a different digest.

You can calculate the sha256 digest using following command on a mac machine (Tested on mojave)

openssl dgst -sha256 <file.msi>

You should provide the hash algorithm used i.e., sha256 along with the digest from the above command which a user can validate on their own machine after downloading your application. If the digest matches the one mentioned on your website then only the accuracy of your application is validated.


What are the best practices in a manufacturing/production facility for data retention?

Never hold anything for longer than you absolutely need it. Your factors in how long that is can include:

legal requirements
financial reporting requirements
regulatory requirements
contractural requirements
legitimate business reasons

I think that the US as a 10-year requirement for financial reporting (it's been a while so I might be wrong).

Your contracts might require longer periods in order to satisfy your obligations.

Yes, there are many who want data "indefinitely", but then they have to define a legitimate reason for it (and that reason will have to stand up to outside scrutiny).

Privacy regulations, in general, have the understanding that personal data must be destroyed when no longer needed. And they have a dim view of "we might find a need later".

Here's your rule of thumb: "personal data is a toxic asset". It holds more financial liability than benefit. You tend to only keep it because you are forced to. But after you no longer need it, and as the benefit shrinks over time, you are just left with a liability.


As documented in this post, Wireshark supports several options for providing secrets to enable TLS decryption. In this case, I would suggest the use of the PMS_CLIENT_RANDOM key which maps the Random bytes from the Client Hello message to the premaster secret (both are hex-encoded).

For the DH key exchange, the premaster secret is the shared DH secret. Using your private DH value and the public parameters and values from the ServerKeyExchange message (see RFC 5246, page 51), you can compute the shared secret. (This assumes ephemeral DH using finite fields, for ECDHE, see RFC 4492, Section 5.4. instead.)

Then after computing the shared secret, you need to encode it appropriately (see RFC 5246, Section 8.1.2.):

  A conventional Diffie-Hellman computation is performed.  The
  negotiated key (Z) is used as the pre_master_secret, and is converted
  into the master_secret, as specified above. Leading bytes of Z that
  contain all zero bits are stripped before it is used as the
  pre_master_secret.

Assuming you have found the secrets, you can write a text file which looks like:

PMS_CLIENT_RANDOM 9c39b93ced5c48db094a502f7ed4ef6b77a1ccb751964c04cac8c7e75837ddc8 2b1f6108824ef0c7e38443dda437c43177d8a1ac73221b6515c9df7d854bc503

and then configure Wireshark as usual via the "(Pre)master secret log filename" SSL protocol preference. If it fails, you can set the debug option at the SSL protocol preferences and read it to get more hints.


Protect Identity with VPN using Cloud Services - Google Drive, Microsoft OneDrive, Dropbox, etc

it's a good question, especially considering that your browser's sessions are primarily saved as cookies and so the ip address you're coming from - vpn or not - doesn't really matter.  As a particularly egregious example, take facebook links on sites.  Those are loaded from facebook, which means you send them your cookie to then request them.  So if you're logged into facebook, facebook knows every site you visit and yes, your Ip too.

So the answer is yes.  To remain more anonymous on your VPN, you should only use incognito or private mode browser and never log into any identifying site that you also use without the vpn.


Do hackers still use iterative password cracking techniques?

To directly answer the question

  how are hackers able to figure out your password using the
  brute-force, iterative method

Generally, breaking a password using 'mass-testing' is done offline. To do this, an attacker recovers a stored password (which is usually hashed) and tries to break the storage security. There is a number of methods that can used for this, depending on how the password is secured (Hash cracking, Rainbow table)

To put it more plainly, if an attacker has a method of testing a password offline, then the lockouts websites offer are ineffective.

An implication of this, as pointed out by Trey, is that if a password is re-used, then an attacker only needs to find the easiest recovery method, and then the attacker has access to any places that password was used. If a site stores a password in plaintext, and it's then recovered, anywhere that password is subsequently used can be considered compromised, regardless of security measures.


How do I resume a dictionary attack using a custom starting number?

Add a -s argument to specify starting point, per Crunch wiki:

-s <startblock>
Optional. Allows you to specify the starting string, eg: 03god22fs


Avoid strong password hashing functions aiding a DDoS attempt on oneself

Your question is almost a duplicate of the one you referred to. Anyway some possible solutions that come to mind to reduce login DDoS are:

(as you stated) Adding a CAPTCHA for every attempt, keeping in mind that most CAPTCHA can also be broken with a certain probability
(as you stated) Random usernames (not using the email and not making usernames public)
(similarly to what you propose) Making the attack more expensive by first requiring the client to solve an expensive computational challenge which is easy to verify by the server
Delegate authentication to a third party authentication provider capable to withstand (or even prevent) DDoS
Two-factor authentication (or even two password authentication), where the simpler factor is hashed with a faster algorithm (e.g. SHA2) and is only used to allow verification of the other factor
Strong authentication with tokens having high entropy (e.g. QR code scanned by a mobile APP) requiring  less expensive hashing (e.g. SHA2, as BCRYPT would give no advantages)

As you also stated, in case of multi-factor authentication the factors less computationally expensive should be verified first and an appropriate delay should be introduced to not leak which factor failed.


How would you set up a ‘cold’ netbook for master-key signing, large Bitcoin transactions, etc?

When you install the Linux OS, you have to assume that the software is the genuine one, free of backdoors. Linux distributions tend to use digital signature on packages; a digital signature does not guarantee absence of backdoor, but it prevents undetected alterations in transit: you know that the package you get is the one produced by the packager. Since you must make this basic assumption, the problem becomes one of networking: how do you get the packages into an offline system ?

There are several possibilities:

Burn a CD or DVD. On the plus side, most distributions can be obtained as a ready-to-burn ISO image, so you just have to make sure that you get the right one (download, compute the MD5 hash, compare with the value obtained from the source site over HTTPS), and you have a whole set of packages. On the minus side, a netbook won't have a CD/DVD reader, so you have to hook up a USB-driven reader.
Transfer the packages with some medium, e.g. an USB disk. As you note, this raises the possibility of a malicious firmware. An alternative is to use a CD/DVD writer, which is a lot more cumbersome, but arguably safer since a CD or DVD does not contain any firmware. In older times one would have used a magnetic support like Iomega Zip drives, but they have become rare nowadays, and are very expensive (in particular considering the size of individual disks: 100 MB... which is a lot when you think about it, but can be cramped with modern fat software).
Use the network. Of course, that's challenging on an offline machine, by definition. You may make a trade-off, with a machine which is mostly offline, but that you occasionally plug to the Internet. You would then want to use a direct ethernet cable, connected to another machine that will do some NAT and firewalling. That way, your security relies on the bridge machine not to be under hostile control at the time you connect.

One may note that for a truly offline machine, that never goes connected, then installing security fixes loses most of its relevance: a patch that prevents remote code execution in some server software is not needed if the said server software is never launched. You could simply run off a "base" set of packages, that you installed from an official ISO image initially.

Network attacks are definitely thwarted when there is no network at all, but you will want to consider other types of attacks, in particular wholesome theft of the device. This is a netbook; it is easy to carry and run away with. On the other hand, you will not keep it with you at all times (e.g. when you take a shower) so there will be periods when the device could be stolen. In that case, you want to make sure that the machine contains no intelligible secret when you are not using it. This points at encryption, unlocked with a master password that you keep in your head, and accept to type when you want to access the data.

You can do encryption on a per-file basis, in which case the tool of choice would be GnuPG (the opensource PGP implementation). To really use it safely, you have to use some care:

Don't configure swap space on your machine. You must run on physical RAM only. Most Linux distribution will want to setup some swap upon installation, so you may have to prevent it or deactivate it afterwards. Not using swap prevents potentially secret data elements from leaking to the physical medium underlying swap space: RAM contents disappear for good about one minute after poweroff.
Use a RAM-based filesystem. When GnuPG decrypts a file, it will write the cleartext as another file, and you don't want that file to hit a physical medium. Instead, you must make sure that you work in a filesystem backed by physical RAM only (type man mount, then search for tmpfs). This implies some care: encrypted files are stored on the disk, but when you want to decrypt them, you first copy them to a RAM-based filesystem and do the decryption/re-encryption there.
Make sure to select a strong password. That is, a random password, not a witty password. See this question for guidance.

You may have noticed that not using swap, and then carving up a chunk of physical RAM for a filesystem, implies higher RAM usage. If your cheap netbook has little RAM, then this may be a problem. A "raw" Linux can run in very little RAM (my first Linux could boot and run a graphical interface in as little as 8 MB of RAM without swapping, but it was in 1994). However, modern Linux distributions tend to eat up a lot of RAM (though not using a Web browser -- since the machine is offline -- will make your life much easier). In practice, I use Lubuntu; for the purposes you envision, you should be able to fit a comfortable Lubuntu with a 400 MB RAM-based filesystem in a netbook with 1 GB of RAM.

An alternative is full-disk encryption. If you use full-disk encryption, you can use swap and do not need a RAM-based filesystem. However, full-disk encryption will have to be done at installation time, and you don't get as much flexibility with regards to algorithms and tools.

Don't forget backup. You don't want to see your secrets stolen, but you don't want to lose them either, e.g. if the netbook, on day, refuses to boot. There again, you will need either encryption or physical protection (keep these CD in a safe), or both.

You will want to avoid forgetting your master password as well. For that, write it on a piece of paper, put the paper in a sealed envelope, and the envelope in a bank safe.


Is a passphrase-protected SSH private key susceptible to a dictionary attack?

It is not the length of the passphrase which matters, but its randomness; namely, how much different it could have been. Length makes room for randomness, but does not generate it.

Symmetric encryption of SSH private keys is not very well designed; it relies on some old features of OpenSSL, which date from before password hashing was a properly understood problem. See this answer for a detailed analysis. Bottom-line is that attackers will be able to try potential passwords by the billion per second, unless you invest some effort into wrapping your key in a PKCS#8 object with PBKDF2 and enough rounds.

If you generate your passphrase as a sequence of letters, each chosen randomly and uniformly, you will get 4.7 bits of entropy per letter (because 26 is approximately equal to 24.7). To reach a decent protection level (say, 100 bits), you will need 22 letters... If you prefer to generate meaningful words, say among a list of 2048 "common words", then you will get 11 bits per word, and 9 words will get you to 99 bits of entropy. There again, each word must be chosen randomly, uniformly, and independently of the other words.

With PKCS#8 + PBKDF2 and one million rounds (OpenSSL would need some coaxing to produce that), you gain 20 bits (because 220 is approximately equal to one million).

Remember that remembering, indeed, can be tricky. You will remember a very long passphrase, but only if you type it often enough. If you don't, then forgetfulness is almost guaranteed. I suggest that you print your very long passphrase and store it in a bank safe (print with a laser printer, not an inkjet printer: ink from the latter can fade away rather quick). Or, simpler, cut the middle man and print the key itself on the paper which you put in the bank safe.

(*) Note: printing systems may keep a cached copy of past printing jobs. Removing all traces can be tricky. You could use a "manual printing" process with a pen and your hand... for really long-time storage, consider engraving on stone or some rust-resistant metal.


SSD Encryption - Difference between models

The ones which are tied to a BIOS identifier are harder to move to another computer - the idea is that they will only work in the computer they are configured for, but this really only works if you have a Trusted Hardware Platform.

You can't circumvent the ones which don't have an encryption key tied to the BIOS password by moving them to another machine - you still need to use the encryption key to get anything off them.

SSD's which encrypt all the data are all secure (secure here can mean many things, but I mean - if you lose the key all the data is inaccessible to anyone. There are some variations, but for consumer grade SSD's this is broadly correct) - it doesn't matter which brand.

You should be able to find vast amounts of information online - both here (we have questions and blog posts on this subject) and all over the Internet, as security of data on SSD's is a hot topic.


Why does the password field not show the entered text?

The primary concern is to prevent "shoulder surfing", where a user is in a position where someone else may see their screen as they enter a password. You don't want users to be forced to secure their visual surroundings before entering a password, as that may not be plausible for them. It isn't always necessary, but it's a good practice.

There is some detailed analysis on the pros and cons of this practice here. (Note the many links to follow.)


How to determine and control extent of data passing through VPN connection?

VPNs have two main routing modes:

Full tunnel - All network traffic is routed through the VPN
Split tunnel - Network traffic for specific ranges is sent through the VPN, but general Internet traffic is not.

Many corporate VPNs operate in full tunnel mode to give their network team more control. For example, you can only browse the Internet through the corporate filtering proxy. Some VPN clients go to great lengths to enforce full tunnel mode, and some laptops are configured so there is no direct Internet access at all, and you have to connect to the VPN to do anything.

A simple way to investigate is to browse to whatsmyip.org and see whether this is your home or work IP address. Or you can use the "route" command to view the routing table. Look for the default route (0.0.0.0) - and see if the default gateway is your local router, or the VPN endpoint. You can also use network monitors (e.g. nettop on Linux; Windows Task Manager has a simple one) to monitor the amount of traffic going through the VPN. It's not so easy to monitor the non-VPN traffic, as the local interface traffic includes the encrypted VPN tunnel.

A common scenario is that your VPN if configured in full-tunnel mode, and you want split-tunnel. If you have control over the VPN software you can configure it to perform split tunnelling e.g. with OpenVPN look at the redirect-gateway configuration option. If your VPN client is locked down, then a good option is to run the VPN within a Virtual Machine. That VM will operate in full-tunnel mode, but network traffic from the host (or other VMs) will not.


How to establish a random OTR remote party as a specific individual?

Verifying a remote party's identity with OTR requires a shared secret (and therefore a prior secure means of sharing secrets) or knowledge of their fingerprint (and therefore a verifiable way to communicate fingerprints).

I'm not aware of any published account of what Snowden actually did in this particular case. One realistic possibility, though, is that he might have used a trusted third party to relay the necessary information.  For example: both Snowden and Greenwald had by this point established secure communications with Laura Poitras - Snowden via PGP, as described in this article in The Intercept (which also explains in some detail how he verified her PGP fingerprint), and Greenwald via OTR, as he mentions a few paragraphs before the passage you quoted. He doesn't state how (or even whether) he and Poitras verified each other's identities, but they would not have had Snowden's difficulty: they had plenty of shared history on which an OTR question-and-answer verification might be based; or they could have verified fingerprints over the phone.

So with these secure channels already established, and assuming Snowden trusted Poitras, he could have asked her to send him Greenwald's OTR fingerprint by PGP encrypted/signed email.


What security features should a smart TV have?

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


Can this bug on Tails Linux/Tor Browser be unsafe?

That is not a bug.

This is part of a temporary fix for an IP leak vulnerability discovered in Firefox related to its file:// handling. See the blog post and the bug on the bug tracker. The behavior was added in 7.0.9 and will likely be changed to a more complete fix when the vulnerability is made public. Until then, the behavior you are seeing is a stop-gap measure to protect from IP leaks.

This temporary mitigation works by blocking embedded resources in resources loaded from your filesystem, while still permitting loading a resource directly. In fact, their temporary solution for the inability to click links is to load the link directly. This is what you are seeing. An embedded image does not load, but when it is opened directly by itself, it displays fine.


Some of these methods are typically dangerous to expose, and some are just extraneous in a production environment, which could be considered extra attack surface. Still, worth shutting those off too, since you probably wont need them:

HEAD, GET, POST, CONNECT - these are completely safe, at least as far as the HTTP Method itself. Of course, the request itself may have malicious parameters, but that is seperate from the Method... these are typically (note exception below) the only ones that should be enabled.
PUT, DELETE - as mentioned by @Justin, these methods were originally intended as file management operations.
Some web servers still support these in their original format. That is, you can change or delete files from the server's file system, arbitrarily. Obviously, if these are enabled, it opens you to some dangerous attacks.
File access permissions should be very strictly limited, if you absolutely MUST have these methods enabled. But you shouldn't, anyway - nowadays, there are simple scripts you can use (if this is a static website - if it's an actual application, just code it yourself) to support this feature if you need it.
NOTE: One valid scenario to enable these methods (PUT and DELETE) is if you are developing a strictly RESTful API or service; however, in this case the method would be handled by your application code, and not the web server.
OPTIONS - this is a diagnostic method, which returns a message useful mainly for debugging and the like. This message basically reports, surprisingly, which HTTP Methods are active on the webserver. In reality, this is rarely used nowadays for legitimate purposes, but it does grant a potential attacker a little bit of help: it can be considered a shortcut to find another hole.
Now, this by itself is not really a vulnerability; but since there is no real use for it, it just affects your attack surface, and ideally should be disabled.
NOTE: Despite the above, OPTIONS method IS used for several legitimate purposes nowadays, for example some REST APIs require an OPTIONS request, CORS requires pre-flight requests, and so on. So there definitely are scenarios wherein OPTIONS should be enabled, but the default should still be "disabled unless required".
TRACE - this is the surprising one... Again, a diagnostic method (as @Jeff mentioned), that returns in the response body, the entire HTTP Request. This includes the request body, but also the request headers, including e.g. cookies, authorization headers, and more.
Not too surprising, this can be substantially misused, such as the classic Cross-Site Tracing (XST) attack, wherein an XSS vector can be utilized to retrieve HttpOnly cookies, authorization headers, and such. This should definitely be disabled.
One other set of Methods bears mentioning: ALL OTHERS. For some webservers, in order to enable/disable/restrict certain HTTP Methods, you explicitly set them one way or another in the configuration file. However, if no default is set, it can be possible to "inject" additional methods, bypassing certain access controls that the web server may have implemented (poorly). See for example some more info on OWASP.


Is it possible for someone to reverse my hash function if he has access to the assembly code?

From the brief description of your hash function, yes, it's likely.

It shouldn't be, if it's a good system (for more on this, see Kerckhoff's Principle).  But when you roll your own crypto, you are almost certainly going to do it wrong (see Schneier's Law).  Please don't.

If you use a cryptographic hash function, then knowing the source is irrelevant, as the algorithms are all public and proven to be secure.

Also, merely hashing a password is not a proper way to store it.  There is much more information on this topic on the third most-upvoted question on this site, How to securely hash passwords?.


Do GPG and OpenSSH use key stretching on their keypairs?

OpenSSH

As of version 6.5 OpenSSH offers a new private key format that supports the bcrypt KDF. The new format can be enforced by passing the -o flag to ssh-keygen. The number of KDF rounds can be customized with the -a flag.

$ ssh-keygen -o -a 1000

References: ssh-keygen man page and Ted Unangst' blog.

GPG

I couldn't find anything equivalent to the above command flags. If there is, let me know in the comments and I'll update the answer.


Are there other things that use the same-origin policy?

All cross-origin access is subject to the same-origin policy. But there isn't one single rule that is equally applied to all methods of interaction.
You might find the distinction betwen cross-origin writes, reads and embedding useful.

Cross-origin network access
The same-origin policy controls interactions between two different origins, such as when you use XMLHttpRequest or an <img> element. These interactions are typically placed in three categories:

Cross-origin writes are typically allowed. Examples are links, redirects and form submissions. Certain rarely used HTTP requests require preflight.
Cross-origin embedding is typically allowed. Examples are listed below.
Cross-origin reads are typically not allowed, but read access is often leaked by embedding. For example you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

Here are some examples of resources which may be embedded cross-origin:

JavaScript with <script src="..."></script>. Error messages for syntax errors are only available for same-origin scripts.
CSS with <link rel="stylesheet" href="...">. Due to the relaxed syntax rules of CSS, cross-origin CSS requires a correct Content-Type header. [...]

(Source)
Cross-origin embedding is the most awkward interaction to control. You want to keep the origins separate but you also want to give the users a seamless browsing experience. That's why embedded cross-origin images inevitably  leak their dimensions and cross-origin frames are potentially  vulnerable to clickjacking.

Might it be better to think of it as "Anything but script tags use same-origin policy"?

As you can see, the same-origin policy also applies to scripts. A document can embed a cross-origin script and work with its global functions and variables but it cannot read the entire source code of the script or catch its errors. The ability to embed cross-origin scripts and stylesheets has given birth to vulnerabilities like cross-site script inclusion (XSSI).


Is it dangerous to pass user input to the require function in Node.js?

If you let users require unexpected files, you will get unexpected behaviour. While it may not be obvious how an attacker could exploit that for anything useful, it is impossible to predict the consequences. That is bad.

At the very least you open up a DoS vulnerability since a user can easily crash Node and force a restart. A few requests like that per second and you are out of business. At worst... who knows?

So what is the solution? I see two possible approaches:

Whitelist. Have an array with allowed file names, and make sure func is in that array before you require.
Make sure you stay in the API folder, and make sure all files there can be safely included. For how to do that, see this question of mine.


WPA isn't that secure, but then again WPA2 is no great shakes either. The main risk is that WPA's encryption is easier to break, and implementing WPA versus WPA2 would make it easier for an attacker to discover your key, which is the same for all devices presuming you are running personal mode, even if you can run mixed WPA/WPA2. WPA and WPA2 share some of the same structural vulnerabilities, so WPA2 isn't so much better that running WPA/WPA2 mode is an enormous step down in security.

Really though, part of your risk assessment should include likelihood, and what the potential impact could be. This sounds like a home setup, what is the likelihood that someone is going to pick your home's WiFi to crack, especially considering that there's probably some open or WEP-enabled networks that are easier pickings. And what is the damage potential if someone was successful? Is there anything in your home that someone would want to specifically target?

Most likely the actual risk is pretty minimal, but if you're worried you could enable MAC address filtering (although a skilled attacker isn't going to be slowed down much by that), or you could buy a second WiFi access-point (dirt cheap these days) and put it onto a DMZ network with no access to your main network.


Any reason NOT to set all cookies to use httponly and secure

Yes, there are cases where you don't want HTTP ONLY or SECURE.
If you need javascript to see the cookie value, then you remove the HTTP-Only flag. A couple cases - some sites track the page state in a cookie using javascript to read and write the cookie value. CSRF mitigations often rely on the server sending a value in a cookie, and expect javascript to read that value.
The Secure flag is more important. If we expect all sites to run over https, and only https, then the only http part is a redirect to https. You never want your cookie sent in the clear. Well, almost never. Here are two cases where you might:

development environments often don't have, or don't need to have TLS certs (though maybe they should).
to track activity that originated on http. You might even use your load balancer to set an insecure cookie before it sends back the redirect. Then your application analytics can track which URLs came in as HTTP. Your load balancer can track which sessions came in as http.

In practice, if you're running an https site, always set the secure cookie, and always error on the safe side by setting HTTPONLY, unless you know your javascript requires cookie access.
UPDATE - TLS in Development
A lot of talk about whether you should or shouldn't use TLS in development. Posted the question here:
Should I develop with TLS on or off?


Python implementation of AES and SHA256/512 that are FIPS-140-2 validated?

In the  FIPS publication you can see different annexes, in the Annex A: Approved Security Functions it says that AES, SHA-256 and SHA-512 are FIPS-140 compliance.

In the FIPS-140 validated list however I can't see any python module. Therefore seems that there isn't a python module FIPS-140 compliance, so you can use whatever python cryptographic module want if it has an implementation for the algorithms that you mentioned, maybe you can use pycrypto to encrypt using AES or to generate a message digest. Also as you comment cryptography could be a good possibility.

Hope this helps,


Is it safe to use different derived keys but from the same passphrase for AES CBC encryption followed by HMAC SHA256 hashing?

You are rolling your own cryptography.  Don't roll your own crypto.  Instead, I recommend that you use PGP or GPG, or use their format: namely, the OpenPGP file format.

You should not use the same key for both encryption and authentication.  I don't recommend using the same key for both AES-CBC and for HMAC.

Instead, I suggest that you derive two keys from the master key.  e.g., Kenc = AES(MK, 0), Kauth = AES(MK, 1), where MK is the master key (an AES key), and 0,1 are two different AES plaintexts.  Now use Kenc as your encryption key for use with AES-CBC, and use Kauth as your authentication key for use with SHA1-HMAC or AES-CMAC.

Alternatively, you can use an authenticated encryption mode, such as EAX, CCM, GCM, or OCB.  Authenticated encryption takes care of deriving keys from a single master key, and takes care of providing both authentication and encryption.

It sounds like you are also making another mistake: using a passphrase as your encryption key.  You should try to avoid using passwords as encryption keys.

Is there any chance you can just use GPG conventional encryption?  GPG has been carefully written and vetted to take care of all these issues.


Spam issue regarding security on gmail app

b) does just looking at an email cause an infection on the gmail app on android?

Just laying your eyes at the contents of spam or malicious email is safe.

Like looking or hovering your mouse over,

a picture with a link embedded
at a malicious attachment
a plain URL

  a) is there any other check I should do?

There's nothing to do because there was nothing that happened. Don't worry.


In order to use ADH (anonymous diffie-hellman) the relevant ciphers need to be enabled by both client and server. This is by default not the case for OpenSSL and for common clients (like browsers) and that's why ADH will not be used.


What's a practical example of a Trusted Computing Base?

A very common TCB, though never named as such, is the late great Blackberry phone. Government parties generally require access to OS source to certify as a TCB, but on top of the stock device may be a government-developed document management client, containerised storage, policies enforcing encryption and complex passwords, screen filters limiting shoulder surfing, and secure destruction procedures.

For most companies that handed these to execs they were de facto TCBs. Obviously government classified systems are more strenuous (see Barack Obama's modified Samsung smartphone).

Another way to approach it is to think of the secure room in Mission Impossible (the movie), but a bit more user friendly. It's a useful extreme at the opposite end from off-the-shelf Blackberry - custom hardware, custom software, custom processes, custom room.

Reality is somewhere in the middle, but the key takeaway us the totality of design, deployment and use.


Firewalls aren't "bypassed" in the sense Hollywood would have you believe. They operate by checking incoming and outgoing traffic against a set of rules. These rules might be based on metadata (e.g. port number, IP address, protocol type, etc) or real data, i.e. the payload of the packet.

For example:

Drop all incoming packets from IP address 1.2.3.4
Drop all incoming TCP packets on port 22, unless they're from IP address 2.3.4.5
Drop all incoming TCP packets with the RST flag set, when the sequence number does not match that of a known connection.
Drop all incoming and outgoing NetBIOS packets.
Drop all incoming packets on TCP port 80 that contain the ASCII string 0x31303235343830303536.

Modern firewalls are usually comprised of the following rule sets:

Base rule set - usually "block all" followed by a list of exceptions for commonly used services / protocols (e.g. outgoing HTTP requests)
Custom rule set - a set of user rules designed to override / complement the base rule set.
Signature rule set - a set of signatures to prevent against known exploits. The last rule in my list is an example of this - it detects the Havij SQL injection tool. These usually override all other rules. This set is analogous to an anti-malware database, and must be updated frequently.

Bypassing a firewall isn't really something that can be done. All traffic that goes through it is filtered according to the configured rules. However, a firewall only does what it is told - a misconfigured or out of date firewall might allow an attack through.

Ways I can think of to get round a firewall:

Literally go around it. Find another entry point to the network that does not pass through the firewall. For example, send some malware or an exploit to an internal user via email.
Exploit a misconfigured firewall by crafting packets that don't trigger the rules. Difficult, but potentially possible.
Send custom exploit payloads to the target on an open port. Firewalls can only identify known exploits.


Is there any defense against Brute-Force done on a local encrypted file?

If the file is retrieved from the filesystem to the attacker's system, there is no longer any gateway. The brute force can continue without any impediment.

More complex keys or passwords do increase the time/cost of brute forcing, but 'eventually' (hopefully before the heat death of the universe), it could be cracked.


What is social engineering, how does it relate to security and how can it affect my business?

When trying to break into a system, one can have multiple approaches. One of the options, that is often overseen, is rather to play the human rather than the machine. One can manipulate a victim into giving him crucial information for the attack or just handing over the information that was the initial target.

It can also mean manipulating someone into not reporting an anomaly or make him use hardware/software (Installing software with a virus/rootkit, inserting a USB drive with a virus on).

Some examples of cases where social engineering had a big impact on a business, some of these I heard through the Belgian Federal Computer Crime Unit, some others through articles.

Case 1: Large package handler looses 3 days worth of package tracking/orders , resulting in a few hundred thousands of euros of damage.

An administrator was fired, the disgruntled man came into the office a few days after he was let go. He made sure it was the less busiest moment possible. He then went on into the system and deleted (including backups) orders of 3 days.
When the man came into the building, an ex-coworker noticed him coming in. Now this man knew the man was fired. The policy of the company also clearly dictated that when an employee sees someone in the building who is not an employee himself and is not accompanied by another employee, the employee needs to alert security.
The co-worker confronted the administrator and asked him what he was doing there. The administrator made a story up saying he was clearing out his office. At this point we see the social engineering event. The administrator makes the ex-coworker think he's there legitemately, whilst he's not. Now the ex-coworker made the mistake of ingoring the company policy.
(Of course other mistakes were made, such as not revoking the rights and access cards to the building immediately)

Case 2: Hackers throw prendrives onto the parking lot of chemical concern DSM
This is a form of social engineering, in the sense of relying on the greedyness or goodness of people. Hackers threw pendrives all over the parkinglot of DSM. The pendrives themselves are infected with a Trojan that installs the rootkit. After analysis it was determined the software was looking for information, possibly company secrets.
The hackers hoped employees would either use the pendrives themselves or put them in their computer to find out what documents are on it to try and see who they belong too. Fortunately the first employee to find a drive brought it to the IT department who did an anlysis of the stick and saw what was on it. They then immediately sent out messages to all the other employees to NOT insert any pendrives they find into their computer. This time there was no information stolen because an employee followed protocol.

Case 3: Hackers pretend to be of the Belgian FCCU, infect the computer with a trojan that auto redirects
In this case hackers pretented to be of the Belgian FCCU and installed malware on a victims PC that auto redirected the victim to a page looking like an official page of the police, stating that he's been disconnected because of downloading pirated software and needs to pay a fine before he can be reconnected again. Hackers use social engineering by posing as officials and threatening the target.

Case 4: Hacker calls victim and bypasses a two-factor authentication
This case happened with a victim that was infected by a trojan. The victim wanted to login into his bank account which used a two factor authentication mechanism. The user has to insert his card into a reader and press the numbers that come onto the screen, provide his pincode and then insert the response into the password field.
The attacker saw that the victim was about to log into his bank account and called him up. He then said to the victim that his bankaccount might have been hacked. He tells him they need to verify his identity, so he asks him to press a button a few times and tell him what number is on there (it's the serial number). The victim now believes the attacker is a bank representative.
He then continued to let the victim enter the numbers he received on his pc to be able to bypass the two factor authentication mechanism. It worked and the victim's bank account was cleared out. This attack is relatively bolt to do, but not impossible. Again the victim was manipulated into thinking the representative was real.

As you can see these can all have grave impacts in day-to-day business proceedings and may cost a company a lot of money. The key is to have special seminars or other means of educating employees and users. Giving them examples of what might happen may result in them making the right decission one day when they are faced a similar situation as the ones above.

As always the risk of this happening has to be weighed to the cost of what might be lost. But in almost every case the risk is higher than the cost to train employees.


Security best practises for my first ever Node, Mongodb, Nginx production app on a Ubuntu VPS

I recommend to have a bastion host to access your server via a SSH-port forwarding agent to tighten the SSH aspects.

Usually I perform OS hardening images using CIS Benchmark guide.

Always focus on 3-tier architecture concepts. I don't recommend to run on the same ports on the same node. You can use docker concepts for your usage.

I use the following:

Nginx for Reverse Proxy (Behind NAT or Direct Public IP) with SSL configuration and its respective encryption algorithms. (Port 80/443)
NodeJS for application tier (parsed from the Reverse Proxy's proxy-pass to custom port, similarity to 8080) using internal IP.
MongoDB connector (Mongoose) on another NodeJS application layer with different running port as middleware. (Port 8000)
MongoDB Server with custom port (you can also use the default port 27017) which only allow the TCP communications within the internal subnet of your docker containers.

Additionally, I don't use ufw. I use ConfigServer Security & Firewall (csf) for easier management for the server(s) since by default it is whitelisted (Deny) and on Test Mode to understand your usage.

Optional: You can use HAProxy as load balancer on top of Nginx and/or your application and db tier dockers.


Encrpyting HTTP sensitive data without SSL certificate

Just don't do it, for many reasons:

RSA by itself should not be used to encrypt many bytes - RSA maximum bytes to encrypt, comparison to AES in terms of security?
Assuming that you are using RSA together with a symmetric cipher as it is usually case the (in)security depends on the details - i.e. symmetric algorithm, key size, integrity protection etc. There are many pitfalls here.
Apart from that the RSA keys not only need to be exchanged first but also each has to be sure that it has the correct key of the peer and not the key of some man in the middle who injected itself during the key exchange.
And it does not provide any forward secrecy, i.e. once a key is compromised (private key leaked) all previous messages can be decrypted.

And these are only the more obvious points. Crypto is a really complex issue and even experts get it wrong. Don't even try to design your own system unless you understand the design of established systems and why they were done this way.


Securing elasticsearch behind a reverse proxy

Reverse proxy is one way to do it.  There are some other plugins that you could put on your elasticsearch cluster that are a bit more robust:

Shield - Commercial license only, elastic.co

  Shield is a plugin for Elasticsearch that enables you to easily secure
  a cluster. With Shield, you can password-protect your data as well as
  implement more advanced security measures such as encrypting
  communications, role-based access control, IP filtering, and auditing.
  This guide describes how to install Shield, configure the security
  features you need, and interact with your secured cluster.

SearchGuard - Commercial and Free licenses, from floragunn

  Search Guard offers the same functionality as Shield, adds additional
  features on top, at a much lower price point and with a more flexible
  licensing schema. Additional features include:

  OpenSSL support Kerberos support HTTP Proxy Authentication support
  JSON Web token support Source code available – run your own security
  audits Licenses for Search Guard are based on production clusters, not
  nodes. That means that you can scale your cluster up- and down as
  necessary, without affecting the license costs. Development-,
  staging-, integration- and QA/AUT-systems are covered by the license
  as well at no additional cost.


By default, smartphones have a lot of services that phone home with diagnostic information that could identify you.

If you root the phone and remove all this, then the phone is basically a computer. Still I would prefer to start from a known baseline (e.g. simple Linux distro) and only add what I need, rather than risk missing a service that identifies me.

For pen testing you don't normally need to be anonymous as you're working with permission. But I've still answered your question as occasionally pen testers have good reason to be anonymous.


Fastest way to "lockdown" CentOS and have network intrusion detection, firewall, etc up and running?

I doubt you will find a One-Stop-Shop kind of solution that actually works well. Your best bet will be to review one of the excellent hardening guidelines and implement what makes sense for you.

That being said, you should probably check out two projects

Bastille
Tiger

If you have a little more resources available some vulnerability assessment products can do configuration audits. For instance, ProfessionalFeed subscribers to Nessus have a large number of configuration audits available, including many CIS benchmarks.

All of these will inspect your install and make some recommendations on what to change or tell you how this install deviates from the standard. However, their base rulesets may very well not work for you. You really need to modify their checks to match how you want your environment to look.


Arp-spoofing local network, Devices can't see eachother

Is your computer in the same subnet than the target devices? Because ARP only works between devices in the same IP subnet.

  But if the two IP Addresses are on different subnets, the device will follow a completely different logic: it will look in its routing table for a route to the destination network, and then it will send its packet to the appropriate router (or to its default gateway if no more specific route is present); in this scenario, ARP will be used to find the hardware address of the router, because the destination IP address has already be deemed to not be directly reachable, so the packet must be delivered to a router which can take care of it.

Look in here for a better explanation.


You would need to extract the key of the card, which is what these cards generally protect against. Authentication protocols in general depend on a challenge response. In case of Mifare EV1 this is done with AES or 3DES. Basically the nonce (incase of DESfire 2 nonces) are encrypted:

Reader sends b1,b2
Card replies 3DES(b1)
Card replies 3DES(b2)
Reader verifies if these nonces have the correct encrypted value and authenticates or rejects

You can't just clone the card, it's not a simple card that simply supplies an ID. In case of this smart card you would need to extract the key which isn't easy.

There is some documentation on how to do this with side-channel attacks.


This depends on your threat model.  If an attacker can get a process list (ps) on your machine at the right moment, they will see the substituted password being passed to GPG.  This is available to a normal user, so also available to any malware on your system, even running as a different user.

You could see this by creating a FIFO for input (so it will block) and running ps aux after starting GPG.  For example:

% mkfifo io
% gpg -q --batch --passphrase `echo supersecret` -d io &
% ps -ef | grep gpg
david    23136 22440  0 19:11 pts/4    00:00:00 gpg -q --batch --passphrase supersecret -d ./io

You can see that supersecret appears in ps output, just as your output of dmenu -P would be.

You should consider using --passphrase-file with redirection through a named pipe, such as:

gpg --passphrase-file <(dmenu -P)

This will transfer the passphrase through a pipe, rather than a command line argument, hiding it from any attacker able to read the process list.

Additionally, the stored data will be left in (physical) memory when the dash script exits, whether or not you unset the variable.  (Unset just removes the reference to the variable.)  There's a high likelihood that if someone physically took your machine and was able to dump memory, that memory forensics would lead to being able to extract some/all of your passwords.  I am not aware of any shell or tool to mitigate this risk.  (There's also a risk that it will be stored in swap, if you use swap.  Consider ephemeral encrypted swap to mitigate this concern.)


How to inject executable, malicious code into PDF, JPEG, MP3, etc.?

There must be some security hole in the application.

Think like any very-simple-and-common .txt file: if you open it with an hex viewer, or with a well-designed textpad editor, it should only display the file content, and ok.

Then think about of processing the file, somehow, instead of just showing the contents. For example, reading the file and interpreting it's values. If it isn't done correctly, this could lead to execution of the bytes that are inside the file.

For example: if you have designed your app to load the whole file and show it, but somehow you have a variable inside your program that only holds 256 bytes. This could make you read (and write to memory) more bytes than your app expected. And, imagine, inside your app there would be any command to jump to position NNNN in memory and execute what is there, but since that memory position was written with data your program didn't expect, then you'll execute some code that shouldn't be there, and was loaded from your file...

That was a buffer overflow attack.

The same could happen with pdf, jpg, mp3, etc, if the app didn't load the data correctly.

Another possibility: for any other reason, the app (or some DLL it loads to read your data) executes some part of the data, instead of reading it. If you know what would be the command (or the data) that would trigger this behavior, you put those commands inside the data file (like the pdf file) so that the app executes it.

PDF virus: read this site: http://lwn.net/2001/0809/a/adobe-pdf-vul.php3 to know a bit about one virus that spread using PDF files.


Let's clear up a couple of misconceptions:

DDoS mitigation partners cannot work unless they can decrypt traffic

Yes, they can - they just can't do it as well, as the content is not visible, so the solutions which work on traffic flow will still work.

Handing your key to a 3rd party is a bad thing

Not necessarily. In fact this is extremely common for large corporates - who typically have their infrastructure managed by 3rd parties anyway. What it does do is require that you replace some of your technical controls with contractual controls, and that you take greater oversight/audit responsibilities over the 3rd party.

Mitigation of the threat of the 3rd party misusing the key, or not protecting it is a straightforward one to assess and then provide a solution for.


Is End to End security possible without physical contact?

I think you need to separate in your mind confidentiality protection from authentication.

It is quite possible to simultaneous generate a key between two parties over the Internet, with everyone from your ISP to every Govt possible listening in, yet they cannot as an eavesdropper also generate that key.  That is the essential point of say the Diffie–Hellman key exchange (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange).  But both parties can use that key for confidentiality protection ONLY; in that scenario neither party truly knows who they formed the key with.

The reason being, if all those baddies on the Internet are active man-in-the-middle, each party could wind up creating a key over-the-Internet with the man-in-the-middle, and be none the wiser.  Hence a proper secure communication system includes authentication first, then confidentiality second.  For authentication, indeed you need some means out-of-band to get the absolutely true identity key of the other party (and there are a lot of ways to do that with varying levels of reliability).  But once you've established identify and authentication of your other party, it is possible to develop keys used for confidentiality purposes over the Internet (by also including the authentication keys in the key exchange process so the man-in-the-middle cannot hijack it).

Re WhatsApp, it gets its security from TextSecure, which relies upon the security of the Off-the-Record Messaging protocol.  Start with the Wikipedia article; it has a subsection that discusses authentication of the two parties: https://en.wikipedia.org/wiki/Off-the-Record_Messaging


How can I explain self-signed certificates to users?

So how can I ensure that when I send a user to my server, and they are confronted with the "self-signed certificate" warning, they are able to decide for themselves whether to trust it or not, instead of having to believe the skewed picture that their software paints for them?

If you are not using pre-defined trust anchors (e.g. the root CA of the browser) you have to find a way to give your users the necessary trust information in a secure way. The preferred way would be of course personal, because any indirect ways like phone call or PGP signed mails need a pre-established trust, e.g. associating phone numbers or keys with you.

  Also worth mentioning is that the certificates are not forever, and eventually expire, so the user must be able to tell the difference between suspicious change of cert...

In this case you have again inform the user about the change in a secure way.

The whole idea of the trusted CA in the browser is to start with some pre-defined trust and then defer trust information about other sites. This is similar to real life: you initially trust some people (parents..) and from them to learn trust other people. But once you abandon any initial trust settings you have to start from zero and thus find your own way to make your users trust you.

If you want to establish your own certificate as trusted you can only start with the existing trust relationships, i.e. friends which know you directly, know your phone number, your PGP key etc. These trust relations then must be used to transport the new trust into your certificate (i.e. fingerprint or similar). The best approach then depends on the kind of trust relations you already have to your friends and which one can be used as the best transport for the new trust.


What (aside from the law) prevents cloud-hosting owners from eavesdropping on servers/code?

Technically, you cannot protect a system against its administrator. So when a company hosts a site or an application in an external computer center, they trust that computer center to behave professionally.
For that reason, it in common not to externalize the most sensitive informations.
As usual when it comes to Information Security, everything ends as a matter of cost and risk. For rather trivial information, the gain of externalization is higher than the risk of stealth, but for highly sensitive information the risk is often bigger than the gain.


Is AES+hash rather than HMAC problematic?

I'm not allowed to comment yet but you don't specify if somebody is supposed to be able to check if a string was created by a specific user.

If that's unnecessary you should probably simply use authenticated encryption.
If somebody should be able to check then I don't know how they would achieve that given your scheme. Even if they have the key, how will they know what was encrypted?

I don't think this can be reasonably answered without more details about your use-case. With the information you have given so far it just sounds like a pretty bad idea.


https://linearalgebras.com/ Is there anything wrong with this site?

It is (kind of) a misconfiguration.

The site is hosted on GitHub Pages and it does not have a certificate configured for the linearalgebras.com domain. GitHub does not seem to offer the option to configure a certificate for custom domains (although it can be configured with CloudFlare).

As GitHub does not block HTTPS connections coming to its addresses and seems to use the same infrastructure for its core services as well as GitHub Pages, any connection coming to the servers will get a certificate for GitHub-owned domains.

That said, there is no security risk in accepting the GitHub's certificate for linearalgebras.com and using the site over HTTPS. The connection would be encrypted and data could not be intercepted by a 3rd party. GitHub as a hosting provider would be able to access the data anyway.

Side note: if you try opening http://192.30.252.154/ (the address DNS resolves to, but without SNI), you'll see the GitHub's 404.


I would recommend the following:

Its best if you deployed a well-tested TLS 1.2 protocol on this device for the purposes of secure authenticated communication rather than invent your own protocol.
Deploy a client certificate on each device and store it as well as the root CA certificates on the device.
Some micro-controllers have an on-chip secure SRAM/EEPROM storage area that can be used ot store keys - e.g. Maxim's MAXQ1010 has a 128 bit storage. Hash the device's certificate and CA root certificates and store this hash value in on-chip secure storage. At startup, the device should generate a hash of the certificate and root CA contents and check whether this is the same as the stored value, if not give an error and refuse to start. Alternatively, store the certificate and root CA within programmable memory for micro-controllers that are one-time programmable.

In summary, by using the current generation of TLS you can rest assured that you've implemented a robust and well-researched protocol. You can then focus your time and effort on developing other functionality of your solution.


Real life examples of malware propagated by SIM cards?

TL;DR: For laptops, you should be fine.

Networks: no advantages that couldn't be gained more easily though the Ethernet port. Can be fixed by having BIOS password and encrypted drive (not a threat).
JavaCard applications: Your computer won't run these. They run on phones and the modem in your laptop likely just issues standard AT commands and doesn't implement the menu / control interface.
Access to the operating system: while the SIM card is a computer of its own accord it has a very limited interface (it is a hardware security device) and would just communicate with the modem in the laptop. If someone wanted to be able to hack the modem they would need to find a specific vulnerability in your particular modem. This is getting to new heights of hypothetical and even then your modem is just talking to the operating system though a standard, secure driver.


To me it looks like your problem is not so much with the injection as it is with the SQL.

You are just selecting first_name from login. You are not selecting password. In an SQL UNION, the column names will be taken from the first query, so you don't have to bother renaming anything. However, if the password is the Nth field in the first query, it must also be the Nth field in the second query. Since the names in the second part is irrelevant you don't nead any AS.
Also, you must make sure that both queries have the same number of columns with the same types!
It looks like the original query only expect one row as a result, so you should probably honor that expectation by adding a where clause. Now you are first selecting all rows in login once in the left part (since 1 = 1 is always true), and then you are selecting each row again in the right part.

You probably want to end up with a query a bit like this:

SELECT * FROM login WHERE email = 'doesnotexist'
UNION ALL
SELECT null, password, null, ... FROM login WHERE email = 'admin@example.com'

Note that in the above query you have made sure the first part don't match anything. Then in the second part you pick your target email and take care that the password end up in the username column (second column in this example).


According to OWASP Application Security any page that can have sensitive information should not be cached if it can be accessed by public shared computers like libraries.

https://www.owasp.org/index.php/OWASP_Application_Security_FAQ

Any page after the user is logged on is much more sensitive and candidate for no-cache than the login page it self (since login page is public).

I think that in the "Cacheable Login Page Found" report they mixed up two concepts. One concept is the caching of sensitive information as included in the page itself. The other is the caching of the login and password information, as part of browser configuration. That I know of, one directive does not affect the other (that is, considering the page as non-cacheable will not affect the ability for the user to store the password on the browser profile).

To ask the browser not to store login information you can use the autocomplete='off' form attribute.

https://stackoverflow.com/questions/32369/disable-browser-save-password-functionality


You can use 'unzip' from fx. cygwin. unzip -l Archive.zip in a terminal/cmd.exe. While it will list dates of the files archive (CTIME and MTIME, perhaps) these are attributes that can be changed by anyone. The creation date of the zip-file is just the time at which it was downloaded/copied to your PC.


Any vulnerabilities in user input to web Server running Apache and PHP?

Using weak comparison in PHP is almost always a bad idea as it can lead to bugs and vulnerabilities. See here for an interesting example.

In your case, it should be mostly ok, although there are some corner-cases, eg "0x000000" == "000", "1e1" == "10", or "0xBEEF" == "48879".

Apart from that, there is no way to compromise the server with just the given code.


My Firebase project has unknown users, has my google cloud service account been compromised?

These accounts might be created by Pre-launch reports by Google bots. I had the same experience, the moment I published an app into Closed testing and enabled all countries these accounts started to appear in my Firebase Authentication Users report.
Try to provide your own Test account credentials in Google Play console under Pre-launch report settings and check if new accounts will still be created.


How to check the authenticity of the root cert of some CA?

You should never ever trust a new root CA unless you really (and I mean really really) believe that it is fully trustable. Even then you should get the CA certificate in a trusted way, i.e. definitely not by downloading it from a site which certificate is issued by the same yet untrusted CA.

The main problem with explicitly added root CA is that any explicitly added CA is automatically trusted to issue a certificate for any domain. This means even if example.com has usually a certificate signed by InnocentCA the browser will also accept without any notice a certificate signed by MaliciousCA, if you have added MaliciousCA as trusted CA. This makes man in the middle attacks or other kinds of domain impersonation by MaliciousCA easy.
Even certificate pinning (built-in or with HPKP) will not help since pinning is disabled in browsers if the certificate is signed by an explicitly added CA, to make legal SSL interception as used in enterprise firewalls and many desktop antivirus possible.


What cookie request is a suspect request?

As long as you have chosen a sufficiently large CSPRNG for the token, checking it should be sufficient. Somewhere in the 128 to 256 bit size should be sufficient.

You don't mention where you're storing the token in the user's browser. Cookies are typically used for this. You should have the Secure and HttpOnly setting on the cookie. Basically, you should take security precautions similar to security for a session cookie.

As far as not finding a matching row in the database, that is not necessarily a problem. For example, a row could be missing because your site deleted it due to it being very old. The security concern would be if someone is trying to search through the tokens to find a valid one. You can just rely on probability to make this impossible by making sure you choose sufficiently long and random tokens.


The answer to this depends on the nature of the site.  I actually think the UX benefits of telling them if the information provided was correct or not, but only if it doesn't impact security.

There are plenty of sites where you are able to enumerate usernames is multiple ways, and they are that way by design.  For example, if you wanted to enumerate Twitter usernames, you could easily do so by seeing if the user's page were available at http://www.twitter.com/username.  Even if that wasn't possible, Twitter provides a nice little API for accessing lists of users.

However, this obviously doesn't work for a site that is even slightly sensitive in nature.  If your site falls in this category and there is no other way to enumerate usernames/emails, then follow your instinct and give the generic message that you will send an email.


EKS managed worker nodes security patching

This is likely to depend on exactly how your worker nodes are provisioned in the cluster.

If you're using unmanaged node groups then the AWS documentation here recommends that the customer upgrade their nodes manually.

If you're using managed node groups , AWS manage the node lifecyle as detailed here which I would take to mean that they will be patched and upgraded by AWS.

Of course if you're using workloads in EKS based on Fargate, the underlying hosts are managed fully by AWS, meaning you don't have to worry about patching them.


Phishing emails sent to my contacts, from another contact

This was a common facet of Emotet, which would not only send spam to people found in your address book, it would also quote older emails of yours to act as Bayesian poisoning. While Emotet has been seized and shut down by authorities, its techniques are not unique.
A piece of malware infecting a computer can harvest contacts. It might be your computer, it might be somebody else in your address book. If you're seeing crosses between contacts of yours that do not know each other, it's probably you (update your a/v, disconnect from the network, reboot, then do a full system scan. If you still find nothing, consider professional assistance since some malware will corrupt your system in order to evade detection once it's installed).
Another possibility is that the attacker is harvesting addresses from public archives of mailing lists.


Michal Zalewski aka lcamtuf made some interesting posts recently and showed some pocs and explanation on how to do it with modern browsers:

read first: post @ bugtraq
History theft with CSS Boolean algebra
Defend Your Spaceship!

very impressive research imho


IPSec has many modes but there are two main forms authentication for an IPSec tunnel via Internet Key Exchange (IKE) - IKEv1 and IKEv2 (newer) which support 509.X certificates or even preshared keys (such as passwords); the IKE mode selected will then use diffie-hellman (if it's selected in the config, for example) to exchange a symmetric key (as you stated) for the tunnel session (if that's the mode you are using). At this point you have a matured Security Association (SA). Now that you have a key that you are going to use for the session, IPSec has two protocols that will encapsulate your tunnel, AH and ESP.  AH, Authentication Header, provides authentication but no encryption of the tunnel. ESP, Encapsulating Security Payload, uses the encryption algorithm (3DES-CBC, AES-256-CBC, etc...) that you selected in the IPSec configuration to encapsulate the traffic (tcp, udp, icmp, etc...) as it makes its way to the other device that you have the SA with.  FYI, some vendors support a mix of ESP/AH protocols.

If you want to know more about IKE and IPSec check out the RFCs, they are really detailed and informative.


A) If you (the application you are using) correctly implements a full disk encryption then yes everything on the disk is encrypted that would normally be accessible via the OS (such as file, metadata, filename, ACLs, etc ... and the whole OS itself). It encrypts at the block level on the hard drive.

B) If its full disk encryption you supply the encryption/decryption application the decryption key at first use (either on boot or when you connect it to the computer) at this point the key remains in volatile memory and the OS/application handles the encryption and decryption transparently as any when the files are accessed.

C) This would be application specific implementation. It may be someone can recommend one, but product recommendations tend to be out of scope on this forum. But looking at the example I am not sure I am aware of anything that does do what you ask as it doesn't actually encrypt the data.


Can OpenVPN monitor my passwords in my browser?

It depends on who manages the OpenVPN server.

A VPN allows you to connect your computer to a remote network in a secure way: the traffic between your computer and that network is encrypted. This protects you from the intermediate networks (including the local one, on which you plugged in your computer) from seeing your traffic (they see a stream of encrypted data).

If you installed the remote OpenVPN server and manage the service then you would be only vulnerable to a backdoor implemented in the software you downloaded. If you downloaded it from the original OpenVPN web site then you are OK.
If someone runs the OpenVPN server for you then it is a matter of trust. They could install whatever they want to spy on your connection.  This also includes the case where the server is be installed on an appliance you receive as part of your Internet subscription (the French provider Free would be an example).

Please note however that most of the well known sites are now HTTPS, which means that the traffic is encrypted between your browser and the target site. This is in addition to the VPN tunnel. In other words, someone spying on your traffic within the VPN will still see encrypted traffic, because of HTTPS (which is completely independent on the VPN tunnel).

To summarize: running a VPN connection to a trusted site is a good idea. Even though you are protected by HTTPS when browsing specific sites, a VPN completely hides the traffic for the local network (and, usually less importantly, for the intermediate ones):

someone looking your traffic will only see one connection to the VPN server without any details
your computer does nor expose any services locally (which may be vulnerable)


Capture Response Attempting to Connect to Open SSH

The command

ssh -v user@ip -o "PreferredAuthentications=publickey" -I /dev/null 2>&1 | \
    grep "debug1: Authentications that can continue" | \
    cut -d : -f 3

The output

publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive,hostbased

How it works

The SSH command connects, but only uses Public Key authentication, using /dev/null as the key
The grep command extracts the log line with the supported ciphers
The cut command extracts only the supported ciphers
As the SSH connection cannot be made with no key, it closes, returning from the command straight away

How to interpret the output

If you see keyboard-interactive, then password auth is likely accepted
If you see publickey, key based authentication is accepted


EIP is a register in x86 architectures (32bit). It holds the "Extended Instruction Pointer" for the stack. In other words, it tells the computer where to go next to execute the next command and controls the flow of a program.

Research Assembly language to get a better understanding of how registers work. Skull Security has a good primer.


Many tools can do that. Regshot, InstallWatch Pro, InCtrl5 are some of them widely used. Get one that fits you well and use it.

From Windows itself, you could use WMIC to track changes using the RegistryKeyChangeEvent class. You would have to create a WqlEventQuery object and use the ManagementEventWatcher to watch over these events. When a change occurs, the EventArrived of the ManagementEventWatcher class is activated.

There are disadvantages to this:

"HKEY_CLASSES_ROOT" and "HKEY_CURRENT_USER" are not supported.

WMI event does not return the changed value and changed type; it only detects the change itself.


Web application reacts differently to Windows reserved names like CON, AUX, NUL

By default on an IIS server the path of a URL is validated by using the same rules that determine whether a Windows file system path is valid. So this is the reason why http://example.com/aux can give an 500 (aux is an invalid directory name) but http://example.com/foo a 404 (foo is ok). This behavior can be disabled by setting
relaxedUrlToFileSystemMapping = true in web.config.

Apart from a possible small information disclosure that you are running an IIS server there is no security problem.


Which ssh exploit works by changing the user name in the middle of the process?

I don't think, there was any vulnerability in this, at least not in openssh. The code resulting in this error was added in this commit and it is referencing recommendation from ietf-drafts. Probably RFC4252, which states today:

  The 'user name' and 'service name' are repeated in every new
  authentication attempt, and MAY change.  The server implementation
  MUST carefully check them in every message, and MUST flush any
  accumulated authentication states if they change. If it is unable to
  flush an authentication state, it MUST disconnect if the 'user name'
  or 'service name' changes.

So I believe it is the highlighted case.


Choosing a session ID algorithm for a client-server relationship

The basic concept of a session identifier is that it is a short-lived secret name for the session, a dynamic relationship which is under the control of the server (i.e. under the control of your code). It is up to you to decide when sessions starts and stop. The two security characteristics of a successful session identifier generation algorithm are:

No two distinct sessions shall have the same identifier, with overwhelming probability.
It should not be computationally feasible to "hit" a session identifier when trying random ones, with non-negligible probability.

These two properties are achieved with a random session ID of at least, say, 16 bytes (32 characters with hexadecimal representation), provided that the generator is a cryptographically strong PRNG (/dev/urandom on Unix-like systems, CryptGenRandom() on Windows/Win32, RNGCryptoServiceProvider on .NET...). Since you also store the session ID in a database server side, you could check for duplicates, and indeed your database will probably do it for you (you will want this ID to be an index key), but that's still time wasted because the probability is very low. Consider that every time you get out of your house, you are betting on the idea that you will not get struck by lightning. Getting killed by lightning has probability about 3*10-10 per day (really). That's a life threatening risk, your own life, to be precise. And yet you dismiss that risk, without ever thinking about it. What sense does it make, then, to worry about session ID collisions which are millions of times less probable, and would not kill anybody if they occurred ?

There is little point in throwing an extra hash function in the thing. Properly applied randomness will already give you all the uniqueness you need. Added complexity can only result in added weaknesses.

Cryptographic functions are relevant in a scenario where you not only want to have session, but you also want to avoid any server-based storage cost; say, you have no database on the server. This kind of state offloading requires a MAC and possibly encryption (see this answer for some details).


The complete encryption scheme you proposed is not at all secure by today's definition; users of a messenger will expect "FORWARD SECRECY" - which means your server must not ever be able to read/decrypt any message-content that is sent from one client to another.

"I read somewhere" is not a valid source for anything security related
mysql is not capable of saving it's backend encrypted directly, you can keep the backend on an encrypted disk but 99.99% of possible attacks will happen when the system is up and running, when disk encryption is useless
encrypting the database backend will not help against attackers who gained access to privileged mysql-login data (like the ones used in your php script)
even encrypting individual fields of the database as opposed of the whole database does not help against attackers who gained access to your php code unless proper forward secrecy of all messages is maintained

Symmetric encryption ("maybe with AES256") is only secure when the keys are exchanged and kept private, you propose to transfer the initial key in plain-text thus relying on the first connection attempt to be secure. This is horrible design for secure applications / data exchange. Why not use SSL/TLS for securing the connection with the server? It basically does what you wanted to do, except the "initial" package is transmitted over a secure connection using an asymmetric encryption method to deliver the symmetric keys used for the rest of the connection. And now you only need to worry about implementing proper forward secrecy.

For more details and proper implementation of SSL/TLS and forward secrecy I recommend reading the openSSL documentation. OpenSSL offers all cryptographic functions required to implement a secure messenger over the internet.


Is HMAC-SHA256 more secure to hide information than SHA256?

Yes, using an HMAC with a sufficiently long secret key should prevent third-parties from being able to brute-force the hashed values and identify their original values. For HMAC-SHA256, a 256-bit key would be sufficient.

Note that you do not even have to associate a unique key per email. As long as you can ensure that the key never leaks, you can use a single key to HMAC all emails. An attacker that knows their email, and the HMAC of their email, should still not be able to brute-force the key. Nor should they able to derive the HMAC of related emails.


You describe three possible attack vectors in your post:

Payment details stolen from an online service.
Taxi driver recording and using your debit card information.
Payment information stolen from your computer.

Of the three, I'd rank having it stolen from your computer as the least likely.  There's very little Linux malware, and most of it is focused around taking over computers and using them as servers/botnet nodes, rather than the typical Windows malware that tries to steal financial or account information.