Chances are, like you've said, you've forgotten the variations of your password.

It is possible that you have had all your accounts compromised, but, unless you're dealing with someone especially malicious and mischievous, they probably didn't go through the trouble of changing all your passwords for two reasons (at least in my mind):

The time and effort required to do this
You would quickly realize something is amiss when you can't log into
    the majority of your accounts; generally a malicious user wouldn't want to be discovered, so they wouldn't change your password in the first place.

So what is next regardless of being hacked? The true first step is admitting you have a password problem. We're all friends here, don't be embarrassed.

The next step is multiple steps, but TLDR; Get yourself a password manager. They are the best way to stay secure and have a variety of strong passwords for each account that you don't need to remember. You only have to remember your master password.

Step 1:

Figure out what password manager you want to use. There's plenty of options out there. Lastpass is a popular option. Keepass if you prefer something open source. There are plenty of options for this step. Some password managers have phone apps as well, which makes it easy to lookup your password when you're not at your computer/you don't want to add the browser extension to the computer you are using. Do a little research if you're feeling scholastic.

Step 2:

Think up a REALLY good master password. One that you can remember. XKCD style passwords, IMHO, are perfect, because they add a fun-load of entropy, and they are easier to remember than randomly generated passwords. Here is some OWASP material on what you're password should be comprised of if you're feeling really policy-oriented.

Step 3:

If you can't get into your accounts, reset the passwords like you have been. It'll be a pain the neck, but its better than throwing random passwords at the wall until one sticks.

Step 4 (AKA the grind):

Now its time to get rid of that common/slightly modified password of yours! Each password manager will have an option to create a randomly generated password. Create NEW randomly generated passwords and change your passwords for every online account you have.

Step 5 (depends on the manager you choose):

Add your passwords to the password manager. Either input them into the actual manager, or my preferred solution, log into ALL of your accounts in order to add the passwords to your password manager.

Step 6:

Breath easy easier.

This, obviously, will not guarantee your safety online. But this makes it MUCH harder to access your accounts. Hopefully hard enough that it's not worth the hassle to get into your accounts. Hope this wasn't all stuff you already knew and it was at least mildly helpful!


What is the rationale for calling setgroups on a list of length one?

It does look like portability. E.g this posting on the Samba mailing list with a patch included, subject line, "setgroups requires at least one group":

  "On some operating systems (in this case BSD/OS 4.2) setgroups must be
  given at least one group.  When no other groups are wanted, it is given
  the same group as the desired effective group (as seen in sendmail)."

This kind of thing is worth mentioning when making a recommendation about a practice.


Answer from:  https://security.stackexchange.com/users/6253/schroeder

Configure node certificates

  The Security plugin needs to identify inter-cluster requests (i.e.
  requests between the nodes). The simplest way of configuring node
  certificates is to list the Distinguished Names (DNs) of these
  certificates in elasticsearch.yml. All DNs must be included in
  elasticsearch.yml on all nodes.

Configure admin certificates

  Admin certificates are regular client certificates that have elevated
  rights to perform administrative tasks. You need an admin certificate
  to change the the Security plugin configuration using
  plugins/opendistro_security/tools/securityadmin.sh or the REST API.

https://opendistro.github.io/for-elasticsearch-docs/docs/security-configuration/tls/#configure-node-certificates

Thanks.


It is a Trojan affects Windows PCs , named TROJ_OBVOD.TA or Trojan.Obvod .
Discovered:    July 14, 2012.
This Trojan connects to the following sites to obtain a list of URLs where the malware accesses/visits for pay-per-click scheme:

{BLOCKED}3.*.in

The list contain a hundred URLs including mine .


If malicious sw has been given root access on Android device, is that phone forever compromised?

When malware has root access it basically means it capable of modifying system files and bootloader. If you trust custom firmwares such as Cyanogenmod you can consider wiping partitions and installing Cyanogenmod alongside with some custom recovery and bootloader. After reflashing /system /boot and /recovery I see no reason to be worried.


Anti Malware systems don't know whether the code you write is in bounds or not, something in your compiled code matches a signature in your anti-virus, hence the alert. You haven't written anything malicious, it's just a coincidence. You could try different compile flags (not sure about how to do that with Borland), or simply restructure your code a bit and the problem will likely go away.


Why would someone submit loads of email addresses to a form that does nothing?

The attacker may not know that the form doesn't do anything. In particular, they may assume that it sends an email to the submitted address (which is a fairly common pattern, used for sign ups). In that case, they could either be trying to annoy people, by having lots of junk sent to them, or to increase the noise level for the email addresses spam filter - if it accepts your emails, even though the user hasn't actually submitted their address, the user may start flagging extra things as spam (resulting in them missing something important, like a password reset email), or the spam filter may start considering more things as "useful", and hence be more likely to allow actual spam through.

I'm dubious that it's a particularly effective approach, given modern spam filters, but it would be low effort.

Another possibility is that they're trying to get your system into spam filter lists. This obviously wouldn't work if you aren't actually sending anything, but it doesn't take a lot of messages to be marked as spam before sites like Gmail start filtering or flagging messages as potential spam.


Who put the killswitch in the WannaCry ransomware?

The bad guys put the killswitch in their own malware. It couldn't be anyone else, since that malware's vulnerability was in the malware's code.

It's common practice for malwares to check if you're in a sandboxed environment to prevent reverse-engineering (via MITM, for example), and to ease development.

They failed to implement a correct check, since the registration of one domain led to the malware being unable to encrypt anything.


There is an obvious part that I missed (no idea how I did) and that solves all of my problems.
That is oidc token can be inspected at the server without needing to make an http request to the oidc provider in the backend.
This way state is maintained at the oidc server, the client will perform the heavy lifting for refreshing the token with the provider and the server remains stateless this way.


why does the first certificate have a RSA public key in x.509?

The public key contained in a certificate can be used in two ways:

It is used to decrypt something that has been encrypted with the corresponding private key (typically to verify a signature)
It is used to encrypt something that will be "decrytable" only with the corresponding private key

There is a great number of certificates on the Web, so in order to trust them, we use third party "Certificate Authorities". You have a list of trusted CA certificates built-in your browser. The main goal of this certificates is to sign other certificates, to prove that they are valid (If someone you trust tells you that another person is trustworthy, you just trust that other person - that is the logic anyway).

That is why we use the public key of the second certificate in your example to verify the signature of the first certificate. But you will then use this certificate for something (encryption, signature, etc.), and that is when you will need the certificate's public key.


... it compares the size of incoming traffic and the outgoing one and see which one matches? Once you understand what inbound traffic is, you can get the IP of the affected client, right?

To do this kind of correlation an attacker would need to have access not only to the endpoint of the VPN but also need to sniff near the entry points, i.e. at the ISP level. This is complicate already and likely only on the reach of government agencies. But it gets even more complicate if VPN endpoint and entry are in different countries with different laws and which might not like to help each other. And with a typical VPN provider used by many users the attacker would either have to do mass surveillance or need to have some idea already which client he needs to monitor for activity.

But if all this is given such correlation is possible. See Could logless VPNs be traced? for more details.

  This same thing can not be done with tor even if it requires more steps?

Tor works differently and the traffic from the same client passes through different nodes and also different exit nodes. Also fingerprinting at the level of the IP stack is no longer possible and timing and size analysis are made way harder too. This and more makes it likely practically impossible for an attacker to demask a user this way although association was done in some theoretical and simplified scenarios. See Why is Tor safer than a proxy? and Differences between using Tor browser and VPN and Tor traffic correlation attacks by global adversaries and How do traffic correlation attacks against Tor users work? for more details.

  If a private VPN is used, then there is only 1 user connected, ..., so the private VPNs is less anonymous than the public trusted ones, right?

A VPN with a single user cannot provide any kind of anonymity if the attacker is able to detect the entry point in the VPN and is able to associate this entry point with a specific user. If the attacker is a government agency and has already an idea which user this might be and only needs some proof then this can likely be done since these agencies can usually require cooperation by the ISP. Insofar it is easier as with a VPN used by lots of users.


How to harden my Buffalo LinkStation Pro?

Maybe I'm missing something here but this seems pretty simple to me: use the standard ACL list to limit access to /root/.ssh/allowed_keys so that only root has access then put a strong password on your root account and block/remove all services like telnet which allow you to administrate the machine without SSH.


why doesn't nmap outputs simultaneously during scan

Because nmap is most often used to generate a result file; if none is specified, the results are written to stdout. That is what you are probably referring to.

It's just easier to have a single routine that collects data and then transforms it in the correct format for output.

More importantly:
Depending on the scan you are executing, there might be multiple results rolling in on different hosts at a time.

Thus, real time output of findings would be unstructured and unhelpful. If you rather want to know more of what is going on in the background, you can use the verbosity and debug flags to generate much, much, much more output.


Add a San(Subject Alternative Name) to already existing cert?

There is no way to change an already issued certificate since this would invalidate the signature. You can also not issue a new certificate using the certificate you have since this server certificate has basic constraints CA false, i.e. can only be used as leaf certificate and not to sign other certificates.

In other words: you need to create a fully new CSR with all the information you want to have and let it sign by the CA. That you don't have the old CSR does not matter since the old CSR is incomplete anyway. But, you could in theory re-create the CSR from your existing certificate only it would miss the SAN the same as the old certificate does.


How to implement CN/DN certificate validation between two internal servers?

I'll not be able to provide an exact answer that will "solve" this problem since in the end it's kind of a broad question that can be tackled in different ways.

For all things related to TLS implementation the OWASP Cheat Sheet is always a great reference and even starting point. It covers a lot of ground and can be useful throughout an implementation or application development.

Regarding your first question, RFC 6125 specifies procedures for representing and verifying the identity of application services in such interactions.

Section 3.1 of RFC 2818 also describes how to correctly identify a Server.

I'm not quite sure what do you mean in the second question. If you're mentioning checks during the TLS handshake or if it's related to authentication. The handshake will only work if the client and server trust each other, therefore if there isn't a trust relationship between the peers the handshake will fail, this is already covered by TLS.


How do you prevent/guard against a wireless disassociation attack

This can be protected from with the IEEE 802.11w, also called Management Frame Protection (MFP), which provides authentication for Wi-Fi management frames, including those related to deauthentication and disassociation. When protected management frames are supported and enabled by both sides, the attack will not work because it will fail to authenticate as legitimate and will be ignored.

According to the above-linked Wikipedia page, the frames that are protected by 802.11w are:

Disassociation and deauthentication
Radio measurement action for infrastructure BSS (802.11k frames)
QoS action frame (802.11e frames)
Future 11v management frames (802.11v frames)

The frames which are not protected due to infeasibility are:

Beacon and probe request/response
Announcement traffic indication message (ATIM)
Authentication
Association request/response
Spectrum management action

Unfortunately, lots of hardware does not support 802.11w, and lots of software does not take advantage of it even when it is supported, so its utility may be limited and you will not often encounter it as an obstacle to deauth attacks. Note that this does not and cannot protect against a radio jamming denial of service attack where the entire spectrum is saturated with noise. However, such arbitrary jamming is far less stealthy and cannot be used for targeted attacks, rendering it a much less likely source of DoS.

As mentioned in the comments, IEEE 802.11w is not perfect, and other denial of service techniques exist. A paper called A Formal Analysis of IEEE 802.11w Deadlock Vulnerabilities shows how deadlocks can be exploited to selectively deny service to any associated clients. The paper concludes by demonstrating the inadequacy of current methods for validating specs like 802.11w and recommends formal methods.


How can I choose a strong password that is easy use on a smartphone?

You actually already have part of the answer: to make it easy to type, use only lowercase letters.

Now the trick is to know how many letters to use. If you want, e.g., 40 bits of entropy (a quite high goal for a password), then you must accumulate at least x letters such that 26x > 240 (i.e. 9 letters). 9 letters are sufficient if they are chosen uniformly, randomly and independently from each other; do not try to do it in your head, the human brain is a terrible RNG. Instead, use a good RNG (coin flips, dice, a computer with /dev/urandom...) and, that's the important bit, stick to the result: you get your 9 letters, accept them and learn them.

If you want to have a password that you can "easily" memorize then you need more letters. For instance, you could generate 100 sequences of 10 letters, and keep the one which pleases you most; since 2610 > 100*240, you still get your 40 bits of entropy.

See this question (in the crypto-specific stackexchange site) for details on the involved mathematics.


Is there any way track a Andriod phone using IMEI Number

Your service provider has a registry with every customer and latest cell id they have visited. In this case the location accuracy depends on the density of cells, usually the radius is something in range of 300-1000 meters. Combining several records, you can triangulate the device location quite accurately.

If the SIM-card is removed and the phone was taken to another network, a.k.a roaming, the location information is only stored by the other service provider. If the sim-card would be in place, the location data would be relayed back to your service provider.

Usually service providers are not interested to give out location data in these cases. It may violate some legistlation, as you could effectively track some other person than yourself, by placing your cell phone into his/hers car etc.. It may also be time consuming for them to dig the databases, so they usually give out this infomation only when requested by the police.

If you happen to remember the MAC address of your phone WiFi-adapter, you could check the DHCP-tables of access points in your area. In the best case, you have some firewall/IDS logs with timestamps. In the best case this will save your day, pinpointing when the device was last seen in the network, even revealing sites visited from the stolen device.


because the password is being concatenated into the command, it seems like an attack as possible, Kind of like SQL injection.

Indeed, it's very easy to do a "; rm -rf / ;"-type attack.

  If I were to blacklist double quotes, would that avoid all potential issues?

It's far more secure to avoid passing commands through a shell at all.  You should instead be using the exec family of functions (or rather, an appropriate wrapper around them in your language of choice), where you pass a pre-parsed command; this is much more failsafe than trying to implement a shell quoting blacklist.  Most language's wrappers will also provide an easy way to pass stdin to the command, which is the only thing you're using multiple processes and a pipeline for.

You still need to consider other possibilities of attack (for instance, does cracklib-check consume a lot of resources when passed a very long string?  Then you've opened yourself up to a classic Denial of Service attack), but it will at least avoid the injection-type holes.


Trust level of whole disk encryption software

I guess it depends on what your threat model is, if the NSA are after you as a person of interest, full disk encryption is the least of your problems, you should probably just stick to a one time pad and abacus.

If you want to keep a potential thief from accessing your documents if your laptop should get stolen, any of the closed source full disk encryption packages will do.

If you're really worried about it, just double up, use full disk encryption from one of the vendors then encrypt the sensitive files with an open source tool as well, the more layers you add the harder it becomes to compromise.

Fyi, Mac has full disk encryption built in: system preferences > system & security > file vault. (Just don't backup the keys with apple)


You're so very close to the name of the Firefox/Iceweasel plugin you need with your question title!

Tamperdata: https://addons.mozilla.org/en-us/firefox/addon/tamper-data/

You could also use one of the Web proxies shipped with Kali, OWASP-ZAP or Burp Suite. You may want to gloss over the manuals for these, but in general you start them up, aim your Firefox/Iceweasel connection at their listening port (typically 127.0.0.1 : 8080) and then they can intercept your traffic and allow you to change post data before it fires.


How do I gain root access to a system using a setuid root binary?

execlp does not have an absolute path for chown here, so you should be able to manipulate the linux PATH variable and get arbitrary code execution. In order to do this, write a simple C program which calls system shell like :
#include ...

void main(){
    system("/bin/bash");
}

Save this file and compile this program using cc program.c -o chown and set execution privilege on it using chmod +x chown
Once this is done, run the vulnerable binary from the path of the evil chown binary like: PATH=. /path/to/vulnerable/c/program.
Your C program will now call our custom chown binary as root and drop you into a root bash shell.


Why am I receiving this error message when browsing nvidia.com?

From the report by SSLLabs:

  Chain issues  Incomplete

This is a misconfiguration of the server: it is not sending the full certificate chain up to (but not including) the root certificate but instead only sends the leaf certificate. Specifically it is missing the intermediate certificate for RapidSSL TLS RSA CA G1. Without knowledge of the intermediate certificates the browser can not verify the certificate chain up to the locally trusted root CA - which results in the error you see.

While desktop browsers often successfully work around this configuration issues this is not successful in all cases.


How can I store a password history to prevent reuse?

Store the old salt and hash values.  Hash the new input with any old salts and see if they match.

If it worked for checking the password when they logged in normally, it will work for checking if the password has been used before too.


Your story is unclear, so I assume a few things:

Alice has an Android device and a computer and Bob has an Android device and a computer. (You said "both have 2", but you mean both have 1 so in total there are 2: one for each person.)
The computers are compromised, but the Android devices are not.
The text file to be encrypted and sent was typed on the Android device.
All devices are contained in separate SCIFs. Communication between the computers goes via a cable and optionally any number of routers or other relays.
The Android device cannot be exploited via the SD Card (e.g. it doesn't run any autorun files, the user does not accidentally run an executable file from it, etc.).
Authenticated encryption is used.

Now to answer your question: yes, in this scenario it's secure, because you circumvented the whole problem.

The point of "you cannot do secure crypto on a compromised computer" is that you do crypto on a compromised computer. In this scenario your Android device does the crypto part, not the computer. Assuming it is not and cannot be compromised, of course it's secure. The computers only act like relays, just like any router on the Internet would when you send an encrypted message.


Should the pentester seek features to test by himself?

There's no scripted answer to this.
This aspect is to be discussed and agreed to by the devs, the security team, their managers, the board, etc. Development and security are tools, the means to an end. If they don't happen consistently and collaboratively you're not being efficient.
a) new features should be planned with security in mind, with the input from the security folks;
b) features are implemented with the intention of being pentested regardless of by whom;
c) issues/faults are supposed to be found, info loops back to the devs and the cycle continues;


Is it possible to detect DPI (Deep Packet Inspection)?

It depends on the kind of DPI you are talking about. If it is purely passive DPI (i.e. only looking at the packets) then you will not be able to detect it. If this is instead DPI which can modify the data then you might be able to detect it depending on the kind of access and knowledge you have.

Some typical examples on how active DPI devices change traffic, i.e. what you can look for:

If you transfer specific data (like known malware) the transfer will fail because the IDS detected and blocked the possible attack. One could use for example the innocent EICAR test virus.
DPI using SSL interception can be detected because the certificate is issued by a different CA.
Some DPI devices strip STARTTLS from SMTP traffic so that the traffic will not be encrypted and can be analyzed. Such change to the traffic can be observed on the client side.
Some devices modify the "Accept-Encoding" header of a HTTP request to strip unsupported compression schemes. This can be observed on the server side or sometimes on the client side too because the content is not transferred compressed.


Custom response for Web Application Firewall (WAF)

I don't think there is a standard way, however there is a code 401 "Unauthorized", 403 "Forbidden", or even the code 450 "Blocked by Windows Parental Controls" and I think cloudfare are using their own codes. My suggestion is don't bring too much information to the attacker about the reason and probably just reject with a 401 or something standard. Take into account that if you respond with a 4xx "Firewall blocked" the attacker will know that you are using a waf.


Qualys WAS raises "150004 Path-Based Vulnerability" on an image file

I'm also trying to figure this one out. So far my conclusion is that you should not block access to js, css or image files in a web application, that is the way is supposed to be.
In my case the scan tool seems to be reading the path of an image(which you can manually do by right click on an image and click on copy image link..) and then changing the image name by a random folder name like Service. The app is returning a 200 status code that contains an error page that doesn't disclose info, it just tell you that something went wrong and suggest you to go to the home page...so in this case I think it should be considered a false positive.
As a side note, if a client wants extra protection of it's images there are some techniques, depending on the technologies been used, that can be applied. A quick search will show some ideas on stackoverflow, but they are programmatic solutions.


Protection from ransomware using virtual machine

There is never 100% security.

There are vulnerabilities in web browsers which also work on Linux
There is malware for Linux. Malware development is constantly evolving. While you are reading this there are hundreds of people thinking about new ways to get those systems under their control which still elude them. Just because you are not aware of any good ransomware targeting Linux today doesn't mean none exist or will exist in the near future.
There are examples of security vulnerabilities in VM software which allow to attack another VM or the host from within a VM.

In order to be vulnerable with the setup you describe you would need to catch a ransomware which targets Linux and includes a VM breakout for the VM software you are using which targets a Windows host. That combination would be quite exotic, but is not completely inconceivable.

By the way, did you consider to invest into a proper backup solution? That protects you from Ransomware and a whole heap of other problems.


Does it really improve security to update PHP interpreter version without any code changes at all?

Considering PHP v5.3 and v5.6 are end of life for a while, no more patches, (security) fixes or updates will become available even if security issues are discovered.

Your hosting provider is quite late in removing these PHP versions considering v5.6 is end of life since December 31st, 2018.

  So, can we say it is "fairly safe" to run an outdated PHP version in an otherwise updated server?

No, we can't. There is no reason to continue using outdated software. The software written in PHP < v5.6 should be upgraded to the newer PHP v7.3 standard.


Does setting a Firefox master password make sense given that full disk encryption is used?

Yes, enabling Firefox master password will provide additional security to your logins. You've also partially answered your question. Even though you've enabled full disk encryption, the master password will protect your logins from other processes.

For example, a malware which has been able to execute on your computer will be able to read the disk contents (like other local processes), but wont be able to read your Firefox saved logins due to the master password.


I would suggest rethinking your approach.

Hashes are not virus signatures; they only serve as a fingerprint to identify files. With most conventional hash algorithms (e.g. SHA256), modifying the input slightly results in an entirely different hash output. Thus there is no correlation between malicious features in your virus files and their hashes. Attempting to train a machine learning model on file hashes would be useless; it would simply overfit the input dataset.

If you're building your AV purely using a hash-lookup approach, your current method works fine. It may be good to find a virus source that provides both the file hash and malware family, thereby circumventing 4 per minute restriction of VirusTotal. If you intend to analyse malicious features in files however, you will need access to the virus files, not just the hashes.


POS still PCI compliant after Single Sign-on?

Assumptions:

Your authentication / SSO solution is completely in-house.
Your POS application is the only covered application at this time.

In this case, your central authentication server would fall into the covered scope and would need to meet security and logging requirements. That other systems rely on this does not make them in-scope.


Given an IP address can you ssh into /tmp without password?

No, you can't. You can't ssh to folders, only to accounts. You might be able to mount the /tmp folder on another machine without a password if the server is running NFS or Samba and has fairly relaxed permissions.


It looks like a directory traversal. To prove whether it is really exploitable I would try to open something more interesting like a script file which is not public available. Otherwise you can't be sure that an attacker can really do something interesting. In my opinion that would be in line with minimal testing. Maybe there is a filter which allows only opening .html and .css files.


nmap traceroute shows only one hop regardless of target

traceroute works by sending packets with a specific TTL (time to live, i.e. maximum number of hops to travel). It expects that these packets get discarded by a system on the path to the target if the TTL is reached and that this system sends an ICMP time exceeded message back.

Since your output of nmap only shows the unlikely result of you being only a single hop away from the target and a very low time to the target it is likely that some middlebox (firewall or similar) at the edge of your local network is messing with the traffic, i.e. it transparently intercepts the connection and answers it directly instead of forwarding it.

  Tracert command on cmd shows the correct result (ie all the hops).

Tracert uses ICMP. According to your output your nmap is using TCP on port 80 instead:

  TRACEROUTE (using port 80/tcp)

Thus the middlebox let ICMP probably pass while it handles port 80 by itself. This is a common behavior with transparent proxies on firewalls.


How can one guarantee that a Diffie-Hellman initial key exchange is not stored?

The analogy of the sending of the box is not quite accurate in any public/private key algorithm. It is only as good as it is something that would work in the physical world. With that out of the way, lets get to Diffie-Hellman key exchange.

Diffie Hellman does not actually exchange keys, it exchanges some information to generate the keys. However it only exchanges part of this information, the rest is kept by each user. Lets go through it, we'll call our users Alice and Bob ;) :

Alice and Bob agree to use a prime number as a modulo p, and a base which is a primitive modulo root of p which is g. These mathematical properties must hold for the discrete logarithm problem the mathematics is built on to hold.
Alice and Bob each choose an integer they keep to themselves, lets call them a and b, then each of them runs the same calculation on that integer, first they calculate g to the power of the integer modulo p. And they send this to each other.

  ga mod p
  gb mod p

Now here is the clever bit, neither now can find out what the others secret integer is, but if they take what they got from the other one and raise it to their own integer and calculate modulo p of that, they both get the same number S:

  (ga mod p)b mod p = gab mod p
  (gb mod p)a mod p = gba mod p

4) Shared number is now used to derive some encryption key for further information.

Without knowing one of those secret integers an attacker can not generate the same number and therefore the same key. Schors algorithm on a quantum computer can solve the discrete logarithm problem to get back those secret integers from the data that was exchanged, but past that or getting Alice or Bob's machine to send them (in which case you can get them to send the derived key, or the unencrypted messages sent/recieved instead).

However if that information did not actually come from the other party but the attacker themselves then without other checks (this is what SSL/TLS certs are for) the attacker can decrypt, re-encrypt and relay the data on.


Is HTML5/JavaScript more secure than Flash/Java, as the browser becomes more like an OS?

Your question is broad and I will try to answer part of it. In my opinion the move to the web, disabling of Flash and Java etc does not make the whole system safer. It just shifts the fragility and exploits to other kinds of attacks. While we currently have lots of attacks at the OS level  and application level (buffer overflows etc) we will have more logic and design problems in the future, which might be even cross-platform. And we can already see lots of these attacks today.

The current design of the web is insecure by default. Inside the web browser security contexts merge, that means it is possible to use the browser as a trampoline to attack internal sites from outside or similar (CSRF, DNS rebinding...). While newer features like WebSockets, WebRTC, CORS... where more designed with security in mind the insecurity of the basic design remains and the new features actually might attack add attack surface.

Attempts to harden the design focus on the transport of the data (HSTS, HPKP) or specific attacks vectors (XSS protection with CSP or some anti-XSS heuristics in the browser) and are mostly add-ones anyway, where the web application must specifically enable this protection on the server side. Content Security Policy (CSP) is actually a good example for this strategy, because it has to be explicitly added on the server side and the application has to be adapted. But at the end CSP just tries to add some security on top of the problem of merging data and code (i.e. JavaScript inline inside HTML) instead of tackling the underlying design problem. And attacks like CSRF also need to be explicitly accounted for in the application with CSRF tokens etc, because by default the application is insecure.

My prediction is that this insecurity by design will give us more of this kind of problems in the future. CSRF, XSS, SQL injection... are application layer attacks and cross-application attacks which all make use of this insecure design. And we will get more of these as long we don't tackle the underlying issues but instead expect all developers to know these problems and explicitly design their applications around the insecure basic design. Today it is easy to write insecure applications and very hard to write secure applications. It is easy to predict what you usually get.

We had such insecure design in the past in CP/M, DOS, Windows 3.1 etc where each application had very broad rights and could cause harm to other applications or even the underlying hardware. This was fixed by adding process isolation, user accounts with different permissions, DEP and lots of other techniques. These were changes to the underlying design and thus increased the security of all applications inside the OS. With the "Browser OS" we are currently at the same level of security as DOS or Windows 3.1. The only kind of (weak) isolation between web applications we have is the Same Origin Policy and this kind of protection can be easily by bypassed with XSS. Unfortunately today's "Browser OS" is exposed to a dangerous environment (the internet) much more than Windows 3.1 was. It will be a hard way to bake security into the design of the web without breaking too much but I see no other option and we should go this way fast.


How is the FileVault master key protected?

(Like you, I am making informed guesses on how things may be done in FileVault.)

If you take a machine, such that, upon boot, typing a given password is sufficient to unlock the contents, without any intervention from external systems (i.e. it also works without a network), then, by definition, that password is sufficient to recover any encryption key and, ultimately, the data. Therefore, if at some point there are two passwords which are sufficient to boot, then the security cannot be stronger than that offered by the weaker of the two passwords. If one of these passwords is "test", then security is not high...

This might be recoverable by deleting the data elements related to the weak password. The conceptual mechanism is that the encryption key for the disk is encrypted, with a symmetric encryption algorithm, using as key something which is derived deterministically from the password (with a Key Derivation Function). Say, the disk encryption key is K, and the recovery partition contains EK1(K), EK2(K),... for keys K1, K2,... derived from the various passwords which can unlock the disk. There can be extra layers of indirection.

If password 1 is weak (key K1 is derived from a "guessable" password), then we want to prevent the attacker from learning EK1(K). Deleting that value ought to be enough, because the attack model is that the attacker, as some time T, steals the hardware altogether, and thus learns all the hard disk contents at that moment, but he has no knowledge of previous contents. This is subject to the following caveats:

Whether the values for account 1, when access is disabled, gets deleted, is unclear. I don't know the answer for that. It is not easily tested (you could try to reenable access for account 1 and see if typing the password for account 1 is needed for that, but even if it is not, it does not necessarily imply that the EK1(K) was kept around, because asymmetric encryption could be used).
Whether deletion from a disk really erases the data is a semi-open question. Most filesystems, when a file is deleted, don't overwrite the file contents; they just mark the space as reusable. When the file is specifically overwritten, whether the data really dies is debated, and the answer is likely to be different for a SSD.
FileVault 2 apparently has an option to store the encryption key (or something equivalent) on Apple's servers, which opens a whole range of new questions about the abilities which are thus conferred to Apple.

To sum up, it seems safer to assume that the data confidentiality offered by FileVault will be no stronger than the weakest of all passwords for all users who ever had access to the disk.


Any decent VPN will ensure encryption, but of course it would have to be configured on each and every machine. IPsec is a VPN technology which has the advantage of being built-in at the IP level and already implemented in your operating system (if it is not, then learn that it is high time that you upgrade these Windows 98 machines).

Note, though, the following important points:

Any attacker would can subvert one of the machines will be able to snoop on every packet that the machine receives and is able to decrypt.
Even if you configure IPsec so that every two machines negotiate an encryption key which is shared between exactly these two machines (and none other), so that a subverted machine may see only these packets which are destined to it, it may happen that this subverted machine, by sending maliciously crafted packets, could redirect traffic to it (e.g. by poisoning the DNS).

That's a limitation of all these encryption setups: they are great at establishing a strong isolation between the local network machines, and the outside world. However, they usually do nothing against local attackers, i.e. attackers who could gain control of one "allowed" machine (as opposed to attackers who just plug into a free switch port or join a WiFi router).

Machine subversion is, unfortunately, a rather common occurrence. It usually goes through email viruses, malware from the Web, even malicious USB keys... (if a user finds a USB key in his mailbox, what will he do ? Well, 95% of the users will plug it in their machine, to see what is on it).

Another important point is that if you succeed at preventing packet sniffing, then, well, packet sniffing is no longer possible. In particular packet sniffing by sysadmin tools that look for malware and virus. Encryption is a multi-bladed weapon.


What approach would you choose to defend againt DDoS attacks from Nginx level?

I would also recommend using:

ngx_http_limit_req_module to limit RPS, and fallback to 503 on burst cap hit optionally. It does very well with exploited zombie browsers DDoS;
agressive caching for anonymous users (with next bullet applied maybe) and for target location (in case it is not random) to eliminate FastCGI passes;
use power of LUA module and bash-fu to integrate with iptables, to block zombies on a system level to prevent concurrent UDP/SSH/whatever-flood (you may consider using ipset utility to handle large sets of zombie IPs which iptables will fail to process fast enough).


The Megan-35 is an encoding and not and encryption.
It is a variant of the famous Base64.

The first step to encode to Megan-35 is to encode in base64. Then for each letter in base64 you will translate this letter to another letter.

You can find a python code on a gist.


Is it possible to detect someone impersonating a device in my wifi network?

MAC addresses, IP addresses, and DHCP hostnames are not security controls.  All of those can be forged.  I can also make my TCP/IP stack look like any operating system available -- the exact same signatures that tools like nmap and p0f use can be used to configure my network stack.

A strong WPA2 passphrase is the only effective wireless network security control most consumer routers offer.  (And since you are using the term "router" for a device that your client connects to, I assume you mean a consumer wireless router.)

There is generally nothing logged on a consumer router that would allow you to detect a malicious device masquerading as a legitimate device.


Acceptably secure solution for users to log in with a short unique code only (no username)

Ultimately, you are the one who will have to make the decision as to what system is secure enough for the context, because that will be based on your threat model, but we can certainly provide some information to help you make that decision.

So, a few points:

The generation method should be a given.  From the set of inputs at your disposal, (be they alpha-numeric characters, a list of words, or any other set of  components a random subset of which will ultimately be the code) each element should be selected using a cryptographically secure psuedo-random number generator. So, that solves the problem of how to generate the codes, and leaves only the problem of what should the codes consist of.
For randomly selected elements, the entropy, which determines the relative level of security is based on how many potential elements you're choosing from, and how many of these outputs you string together.  So, for a 6 character code, using all 26 uppercase letters and 10 digits will give you just over 2 billion possible codes, (36^6, or 36*36*36*36*36*36) for ~31 bits of entropy. (36^6 is roughly equal to 2^31) Now, if we were taking about protecting password hashes against offline brute force attacks, this would not be nearly enough to be secure.   In your case however, if it is as it sounds, and they're not really protecting anything but serving more to identify users on first access, then coupled with reasonable additional security measures such as rate limiting access attempts and securing the database and database access properly, it may be perfectly adequate.
If you were, however, to use the Diceware list of 7,776 words, and choose three random words from the list, the number of potential codes would skyrocket to over 480 billion, (7776^3 or 7776*7776*7776) giving you over 38 bits of entropy. (7776^3 is between 2^38 and 2^39) Still not great for a user's password, but quite probably good enough for a default code.  Besides, AOL used to use this system for default passwords for years, and it seemed to work well enough for them.  (And they only used two words!)
If you want to use your [adjective] [noun] construction, then you'll have to figure out how secure it will be based on the word list you use.  For two words, you would multiply the number of words in the list of adjectives by the number of words in the list of nouns to come up with the number of potential random codes.  A bigger number means more security.  So, if you have 2000 adjectives, and 4000 nouns, your security level would be 2000*4000.  If you added a second adjective, 2000*2000*4000.

So, now that you know how to gauge the relative strength of codes generated using different types of input components, you can make a more informed decision as to which will give you the margin of safety you need, and then there are a few other things to think about for the system as a whole.

As mentioned earlier, rate limit code use attempts.  For a niche system with a small userbase, there's no reason you should need to allow the system to process hundreds or thousands of code access attempts per second.  The only thing that would cause those volumes of traffic would be an online brute force attack.
Protect your database.  If you have SQL injection vulnerabilities in your website, it doesn't matter how good your codes are...The attacker will just dump them from the database and use them at his leisure.
Discard used codes.  Since they're only used for initial access to the system, presumably the users can chose a password of their own at that point, and the code becomes redundant.  They should not be left in the system in a state where they can be reused after that point to access the user's account.

From what you've said, it sounds like the level of risk here is relatively low, so I don't know that I would be too concerned, whatever you choose.  Hopefully the guidance above will help you to be more comfortable with your decision, and better able to justify that the decision you end up making is indeed adequately secure for the system in question.


The most common things are default configuration and outdated software.

So, in order to be safe, first be sure that you are using the latest software provided by the vendor.

Then change the default configuration. This include users and passwords, ports and any other relevant option you see.

Finally, be smart. Don't allow external traffic to that device if you are not going to use it outside of your home.

Basically, "hacking" of these kind of devices follow the steps I just described:

Use Shodan to scan for the device (that is, the device is reachable from Internet)
Try to log in using well-known default users.
Look for the software version and check if there is any vulnerability reported for that version, and if that's the case, check if there is an exploit available for it.


What is the attack surface on a L2 switch?

Attack Surface:

Management
Traffic Isolation (VLAN)
Traffic Monitoring / Sniffing
Actual Traffic Passing / extra services

Management

Look at the management interfaces. A cheap switch example is a home router. Yes, it does more than switching, but the bugs are in the management interfaces. Similar to even the "top" tier cisco devices. Most of the CVEs are around baked in credentials, problems with the management, or problems with implementation of complex protocols.

Traffic Isolation

Many L2 switches will setup VLANs which should be isolated networks, and often we depend on this isolation for security. If you are using an L2 switch in this mode, then a compromise of the management or of the VLAN tagging that allows you to hop VLANs is your biggest worry.

If you're not segmenting traffic by VLANs, I'd argue the security of the switch really doesn't matter.

Traffic Monitoring / sniffing

Take the next level. You can setup a span port and monitor all traffic from all other ports. I personally assume any traffic that leaves my device will be monitored. So I focus on transit encryption. And in today's WiFi world, it's pretty typical for may devices to sniff your traffic. Maybe not a strong threat.

Actual Traffic Passing and extra services

What's left, actual traffic passing. These are the bugs that the NSA used to hack firewalls from the public internet. They find bugs in traffic that isn't simply passed from port to port. Spanning tree, VLAN logic, and the like. This is the stuff where the remaining attack surface lies.
Example:

Cisco CDP DOS
vulnerability in the Simple Network Management Protocol (SNMP) running on certain models of Cisco Catalyst Switches


Should one encrypt traffic even when using HTTPS?

If the communication is happening over HTTPS then it is already encrypted. HTTPS includes the SSL/TLS end-to-end encryption between client and web server.

So in short, no, you do not need to encrypt it any further provided that you implemented HTTPS correctly.

For more details, see this post: How does SSL/TLS work?

UPDATE in response to the update to the question:

If an attacker is in "control of" the user device running your app, security is compromised no matter what way you look at it. Your encryption/security procedures kick in before the sensitive information is being communicated over the network. However, while the user enters, say, his credit card number on his cellphone, it is still in plaintext and vulnerable to the attacker in control.

So yes, you can rely on TLS to secure the credit card information being sent. But there's not much you can do as an app developer against an attacker in control of the device.


will my ISP know my connection between systems in same network?

Your public IP is owned by your ISP, which means that the other IPs in your network are also owned by your ISP. Even if the other IPs are not owned by the same ISP, the packets still travel over your ISP's network to reach the other network.

So, yes, they will see everything, because they are handling the traffic.


How to determine IP address of target device or network

This is the combination of two stages of penetration testing, known as information gathering and enumeration.

Information gathering is the preliminary process of collecting information about your target. This is often divided into passive (no contact with target) and active (contact with target). It can take many, many forms from social engineering, nameserver enumeration, website research, and more.

Enumeration generally refers to discovering and listing resources within the network, such as servers or user accounts. Typically, this phase occurs after the attacker has already gained access to the network, but in cases where the configuration is poor or data is otherwise leaked, it may be accessible without such a foothold.


Email account 'hacked'; do I need to regenerate my server's DKIM _domainkey?

For posterity I'll add my own answer to illustrate the procedure I went through.

Step 1) Discover which accounts are sending spam

Log into WHM and go to "Mail Queue Manager". Do searches and view the emails to see which accounts are responsible. If for some reason you don't have access to WHM, chat with your web host to get this information.

Step 2) Change Passwords

Log into cPanel and change the login credentials for the affected accounts. Those affected need to be notified over the phone/in person of their new passwords.

Step 3) Remove backlogged spam messages not yet sent

Initially I had just changed the email passwords but I kept on receiving notifications of failed deliveries, so I figured "something was still sending emails". Turns out there was a backlog dating back four days with spam messages that had not yet been sent. Return to the Mail Queue Manager and delete the spam messages.

Step 4) Run Antivirus/Anti-Malware Scans

Run on all potential entry points...user PCs and the mail server itself.
For the mail server, I'm on CentOS so I could install maldetect
.
For personal PCs/workstations, if you find keyloggers make sure to change the email account's password again after removal of the logger.

Step 5) Keep an eye on the Mail Queue

Since the spam mail was generated in huge amounts, watch the mail queue to see if lots of emails are still being generated (this might be difficult if you have a lot of users).

I'd appreciate any additional tips that I may have missed.


Content Security Policy (CSP) alternatives

The CSP attribute strict-dynamic was introduced to solve the problem of CSP becoming essentially unmanageable.

What does strict-dynamic do?

The idea of strict-dynamic is the following: Generate one piece of JavaScript that you trust, and use this scrip to load all other scripts. I like giving it a fancy name such as OneScriptToLoadThemAll.js, but for the purpose of brevity, I'll refer to it as the "root script", as you can imagine the trust propagated by these scripts like a tree.

What does the root script do?

The root script's goal is to load every subsequently used script. This script can also be used to add event listeners (e.g. onclick, etc.) to objects, and these would be trusted as well?

What can I do if I really hate CSP?

You can choose not to use it. It's not considered best practice though. If your code relies heavily on adding inline code originating from countless places, then you should refactor your code instead.


Strategy/structure/roadmap to learn Pentesting

How do I get a deep understanding of common vulnerabilities and how to
  exploit them?

There are papers about vulnerabilities which describe the attack vectors, a deep knowledge of the used functions and programming and scripting languages may be required. Generally you learn by auditing and testing code and learning the OWASP cheatsheets for common webapp vulnerabilities.

  Program/List/FAQ/Course about pentesting that guides you from easy
  things to the advanced stuff?

There are some institutes and websites which provide free and paid trainings and courses and free papers. But you should also practive on real webapps, read exploits and try to understand how they work.

Best way is to learn the languages, their functions / methods and their pitfalls.

As software- or webdeveloper you have a much better overview when writing and reading code.

Here are some helpful ressources:
https://github.com/enaqx/awesome-pentest
https://github.com/sbilly/awesome-security#scanning--pentesting

OWAS ZAP is a well known pentesting tool and OWASP has many articles and cheatsheets about pentesting and security.

https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet
https://www.owasp.org/index.php/Category:How_To

You may take a look at the SANS Institute reading room:
https://www.sans.org/reading-room/whitepapers/testing/

They also provide courses, trainings and certificates.


How should I share a TOTP shared key with my users?

I would argue that it depends on your specific case. Remember you need a client that will store the secret key (safely) and generate a TOTP. There are a lot of apps that do that already like Google Authenticator that you mentioned above. You could even create your own (although not recommended ). Most TOTP client apps give you 2 options to add a TOTP key scan QR and insert a key. Although they seem different they are the same (it's a key just in another format).
So your problem is what medium you should use.
First, I have to point out that it will always depend on the level of security you want to have. Too much security is not always good.
Having said that I will list my criteria when choosing a channel to transport a secret.

The channel should be end-end encrypted

SMS do not offer such a service an as such I wouldn't like to use them
Emails do not at least most of them offer end-to-end encryption (plus they are mostly stored at plain text)

The channel should ideally guarantee the end-user identity

SMS suffer a lot from sim swap attacks
Emails accounts can be easily be taken over if the user is reusing passwords and etc...

Both of the above problems are already solved for you if you use the browser as your medium. End to end encryption is provides by the HTTPS protocol and you have authenticated the user with whatever method you deem acceptable. Plus you don't have to relay in third party entities security polices (phone companies, email providers)
All in all I would prefer to use the already existing HTTPS session to transport the secret to the user. If this method doesn't suit you, you can even break the secret into small parts and send then with different mediums. This way even if one of them is compromised access the attacker can't gain access. This however is not as user-friendly. As I said above to much security can be bad.
As far as your concerns about generating a new key for HOTP every time remember.
Also the key should be shared with the user only one time and never again
When a new key is the old must no longer work and ass a result HOTP code that is generated with the old key should be invalid. Also, the process of generating a new HOTP key should be quite thorough to make make sure the one requesting the generation of a new key is the users.


How hard is it to read flash memory off a chip?

It largely depends on the chip and the person that programmed it. Microcontrollers usually have a feature that allows you to pull the existing firmware binary off, but in many cases that can be disabled with a so-called "secure flag", which disables the download process until a new firmware is uploaded containing directives that turn the secure flag off. Of course, this wipes the existing firmware in the process. Check the datasheet for the microcontroller for specifics.

If it's a microprocessor (as opposed to a microcontroller) then there is usually no on-chip firmware, and the program code is stored externally on a memory device. Usually this will be an EEPROM or a mask ROM which you can interface with separately. I've done this with embedded systems that use SPI flash - just desolder it and hook it up to a Bus Pirate. If you can't desolder the device, it may also be possible to sniff the bus and gain information that way.

The universal way to get at the data is decapping. You get some strong acid (nitric acid is a common choice) that will eat away and the package compound, but not the silicon, and leave it in there for a day or two. You then take photographs with a digital microscope and use image processing to turn the patterns into data.


What are the implications of storing sensitive data in bookmarklets?

You shouldn't store sensitive data in bookmarks because people will not expect you to and they will therefore not treat the sensitive data appropriately.

Essentially it is no different to the "remember my password" option provided by the browser or the OSX Keychain, except it is less protected, and the user and their systems administrators may not understand that the need to protect it.

IE's "remember my password" is protected by DPAPI. OSX KeyChain is similar. KeePass requires an additional password. That's why they are "more protected".  But the main point is people know those contain sensitive data and they will typically be treated appropriately by the administrators of the system.

But a bookmark is just a bookmark, right? Nothing sensitive about that is there? Sync & Share it all you like, right?

You should allow the user to use the appropriate keychain/password safe software for the system they are on. I.e. just let the browser "remember" the password if they wish, use OSX KeyChain, KDE's KWallet, Gnome's GnomeKeyring, KeePass and so on.


Ruby resources for Penetration testing/testers and ethical hackers

I'm a Python programmer myself, in my opinion there isn't any limitation to Ruby compared to Python when it comes to coding your pentesting tools. So if you are familiar with Ruby, go for Ruby. It can be handy to understand other programming/scripting languages to analyze an exploit. From this perspective I'd encourage you to try and port exploits from Python to Ruby.  Apart from the more low level stuff in Python (stuff which requires ctypes might take a bit more time to understand) you can generally just look at the protocol spec or Python code to find out how it works.

Metasploit was completely written in Ruby, have a look at the framework as you will most likely use it a lot.  If you want to code your own pentesting tools then just port Python scripts to Ruby or take the concepts from the tool's description..

One of the more interesting tools you have in Python is scapy. It was the pioneering library for packet crafting. For Ruby you have Scruby(not actively developed anymore) and the more recent and maintained PacketFu.

To automate nmap scanning you can use ruby-nmap which is an interface to nmap.


Is it safe to use an AD account to run an App Pool in IIS in order to provide SQL read/write permissions to a web app?

From my point of view your concern is valid.  And managing access from
  your IIS web server to your SQL server database with such
  configuration is a good approach. It is also true that if your web
  server is compromised by a malicious code execution (source),
  attacker could elevate privileges, collect credentials, impersonate any IIS App Pool account and get access to your SQL Server. I can suggest the following and specific security recommendations to increase your architecture security :

Lifecycle management for service account:

Define a password policy rotation to frequently change passwords (some Password Access Management solutions can address this problem)
Use complex password policy
To reduce workload from previous points, use Managed Service Accounts (source). They will provide accounts with complex passwords and automatic rotation
Respect the least privilege (as mentioned by @Jeroen) for each of you App Pool and never grant full admin or DB admin privileges to a service account
Use Kerberos authentication (not activated per default). This will require several configuration (source) and usage of SPNs

Server security:

Enable Windows advanced logging and PowerShell logging to detect strange behaviors (like new process, application crash, failed logons, new service, lateral movement...)
Enable SQL Server logging
Enable IIS logs (txt format files)
Do not store front end servers in the same network or subnet than your sensitives servers (eg: database servers, AD, PKI, ...) and use a firewall to filter only the necessary traffic (in your case the port used by your SQL instance).
Switch your IIS server to Core mode (source) to reduce its surface exposition

  So at the end there is no "magic" solution to address your issue, except following basic and advanced security best practices. Having a log collector (eg: SIEM) in place will be also helpful to increase your security coverage from all your logsources (firewall, Windows, Linux, Unix, routers, IDS, IPS, ...).


How to convert my cert chain to PFX without a password

I'm not sure what Azure means by 'without a password'. OpenSSL can create a PKCS12 with the contents unencrypted, but it still has a PBMAC which uses a password -- but which a reader that violates the standard can ignore. If that is close enough, if you have the separate key and cert both in PEM:

 openssl pkcs12 -export -keypbe NONE -certpbe NONE -in cert.pem -inkey key.pem -out out.p12
 # if you need to add chain cert(s), see the man page or ask further

otherwise since you have an existing pfx:

 openssl pkcs12 -in old.pfx -nodes | openssl pkcs12 -export -keypbe NONE -certpbe NONE -out new.p12


Can we control the SSL version for ClientHello

Yes. At least in Firefox (I'm running 26.0).  Open a tab to about:config.  Filter for tls.version  and set the min/max appropriately. Here's the breakdown of the meaning of the values.

You can also mess with the accepted cipher suites via options (filter about:config for: security.ssl3).

You can test your browser SSL/TLS options by visiting: HowsMySSL.com

Good luck.

(Of course, if, instead, you're looking for a general/OpenSSL answer, the API documentation is your friend. :-D )


Does a continuously freshly installed proxy server increase security?

The specific proposed approach of rebooting full server instances every n minutes would in practice be far too operationally expensive and fragile to entertain in a production environment, but the ideas of:

automatically refreshing one's plant on a regular basis
disallowing durable writes on edge services (except perhaps for logging)

are good ones for security and other reasons and are common threads in DevOps practices going back decades.

Most recently, container technologies now embody these and related practices:

containers are quick to "boot" and can be efficiently used for applications whose lifespans are measured in high tens of seconds to low numbers of minutes
containers are immutable after creation, so file system writes are not durably retained
containers provide additional sandbox capabilities for constraining application access to sensitive resources
platform dependencies used in containers can be inspected and new container templates cut when needed, an improvement over the fragile practice of deploying patches

Take a look at Docker, "cattle vs pets" and "immutable infrastructure" to learn more.


Is it safe to use HMAC with a public key for the purpose of salting?

The username (Or user id) is not a proper salt. Salts should be unique for each combination of username+password, that means if the user changes the password the salt should change too

The salts should be generated randomly upon password changing (Or when the user registers) for example reading from /dev/random or some function that generates cryptographic random numbers. About the length of the salt, it should be long enough to ensure it never repeats


Can the xor of two RNG outputs ever be less secure than one of them?

There are details.

It rather hinges on the notion of how different, or, more adequately said, unrelated, your two RNG are. Let's see it with cryptographic eyes.

"Breaking" a RNG means observing n bits of output and then predicting the n+1 bit with a success probability substantially better than 1/2. A cryptographically secure RNG will in practice be a cryptographically secure PRNG which deterministically extends an internal state into as many bits as requested. We assume that the attacker knows the code (if only through reverse-engineering, or through paying beers to the guy who did the development); so a RNG output is exactly as unknown as the internal state of the RNG. The generic attack is exhaustive force on the state value, and this will be way too expensive if the space of possible state values is huge (e.g. more than 128 bits). The PRNG is cryptographically secure if the best known attack is the generic attack and that attack is indeed infeasible.

The formal setup is that the attacker is given the n bits of RNG output (let's call it r1), and challenged with predicting the n+1 bit. Suppose now that the "XOR of two RNG" turns out to be weak, meaning that given r1 XOR r2 (an n-bit sequence), the attacker can compute the n+1 bit of that sequence with probability higher than 1/2. Then the attacker just has... to produce r2 himself ! He builds the second RNG and runs it, with an output r2 that he perfectly knows, and XORs r2 with the given r1. He then applies the "attack on XOR" on the XOR result, and this yields the n+1 bit of r1 XOR r2. But the attacker knows the n+1 bit of r2 with 100% reliability (he generated it himself), so he can compute the n+1 bit of r1.

This argument shows that the XOR of two RNG cannot be weaker than either RNG alone... provided that the formal setup above is a correct description of the reality.

Indeed, the implicit assumption here is that the two RNG are sufficiently unrelated to each other that a formal attacker can, from the outside, build a proper emulation of the second RNG without knowing anything about the first. This is not a given. In practice, on a given machine, each good RNG will compute the initial value of its internal state from measures on "hardware events" (e.g. times of occurrences of hardware interrupts, with clock cycle accuracy); and both RNG run on the same hardware at the same time, so they see the same events... This implies that the formal description above does not match practical situations, and this invalidates the mathematical argument.

A contrived example will highlight my point. Suppose that RNG1 takes an initial seed S and uses it as key for AES in CTR mode (encryption with AES of successive values of a counter, starting with 0). This is a good, strong RNG, that cryptographers would not shun. Now define RNG2 also as AES in CTR mode, but such that each output bit is reversed (a bit of value 0 becomes a 1, and vice versa). Seed RNG2 with the same S. Taken alone, RNG2 is easily shown to be as cryptographically strong as RNG1. Cryptographers would readily bet a pint of Guinness on its strength. However, suppose that you XOR the outputs of RNG1 and RNG2 together; you then get... a long sequence of 1's, not a single 0. And that's very weak, because the n+1 bit can then be predicted to be a 1 with 100% reliability.

Yet RNG1 and RNG2 are, without any doubt, "different". They don't produce the same sequence of bits. This shows that "different output" is not the good notion here. What we want is unrelated RNG which is formalized as: an attacker can build an emulation of the second RNG without knowing anything about the internal state of the first. If both RNG are seeded from the same hardware, then the two RNG cannot be blindly assumed to be "unrelated".

Conclusion: the XOR of two RNG which run on the same hardware may, in practice, be weaker than either RNG alone. Whether the XOR is strong hinges on "how well" the cryptographic entrails of the PRNG can hide a common seeding. On the other hand, if you can arrange for unrelated seeding (you seed RNG1 with a seed S1, and then RNG2 with another seed S2, and you have good reasons to believe that S2 is unrelated to S1), then, in that case, the XOR of the two RNG cannot be weaker than either RNG alone.

I suggest that you do not indulge in such games. XORing two RNG together will give you some guarantee of security only if you know enough on how they are seeded that you could ascertain whether either is strong alone. If you know that one RNG is strong, then just use it. And if both RNG are weak, it is quite possible that the XOR of the two will be just as weak. The only sure thing about XORing two RNG together is that it increases computational cost and, more importantly, complexity. Complexity is bad for security.


Is the following authentication scheme secure?

If it goes through SSL/TLS, which ensures server authentication (the client is sure that it is talking to the right server) and confidentiality and integrity of the transmitted data, then there is no snooping to fear -- or, rather, if snooping occurs, then it must be right on the client or the server, at which point you have bigger problems (if an attacker can read sent data on the client directly, then he can probably log keystrokes as well).

If we consider your password-hashing scheme by itself (i.e. without taking SSL/TLS into account), then it has a few problems:

You include your "salt" by simply appending it. There is no proof that this will not cause problems with SHA-512. SHA-512 is a Merkle-Damgård hash function, which means that it is a bit less than ideal; it has some structure (e.g. the "length extension attack"). This does not mean that SHA-512 is broken; only that you handle it as if it was a Random Oracle whereas it is "just" resistant to collisions and preimages.
You do not iterate through enough invocations of the hash function. This makes the process too fast: an attacker observing the resulting hash may "try" potential passwords, and will be able to do so at high speed (millions of passwords per second, with a simple PC). This is called a "dictionary attack" and it tends to work because users are bad at choosing and remembering good passwords.
You use SHA-512 instead of SHA-256. You talk about an "interpreted language": if that is Javascript, then that language is grossly inefficient with 64-bit operations (SHA-512 is full of them), so using SHA-512 instead of SHA-256 severely limits the number of iterations you could perform on the client system; this correspondingly boosts efficiency of the dictionary attack.

Usual recommendations for password hashing are PBKDF2, bcrypt and scrypt (my personal favorite being bcrypt; PBKDF2 was not initially designed for that, and scrypt is still too new to be generally trusted).

There are authentication protocols which are, by design, immune to offline dictionary attacks: they are called Password-Authenticated Key Exchange. PAKE protocols allow for mutual password-based authentication between client and server, in such a way that a snooping attacker, or even an attacker who impersonates the client or the server, cannot learn anything which would allow him to "try passwords" on his own systems. The attacker is restricted to online dictionary attacks: each password guess involves interaction with either the client or the server. The most known PAKE protocol is SRP which has been integrated into SSL/TLS. With TLS+SRP, you get a secure data tunnel in which the server and the client are mutually authenticated with regards to the password, without any certificate at all (that's the most brilliant part of it). As a bonus, the server doesn't need to store the password in cleartext, only a value derived from it (as if it was hashed) so an attacker dumping the server database does not learn the passwords (he does learn enough to perform an offline dictionary attack, though). GnuTLS is a library implementing SSL/TLS with SRP support.


PHP crypt() or phpass for storing passwords?

For storing passwords, use PHPass

example of code using phpass:

require('PasswordHash.php');

$pwdHasher = new PasswordHash(8, FALSE);

// $hash is what you would store in your database
$hash = $pwdHasher->HashPassword( $password );

// $hash would be the $hashed stored in your database for this user
$checked = $pwdHasher->CheckPassword($password, $hash);
if ($checked) {
    echo 'password correct';
} else {
    echo 'wrong credentials';
}

internally, PHPass uses PHP's crypt() function, but all the nasty details have already been solved.

Currently, using CRYPT_BLOWFISH is the best practice.
CRYPT_BLOWFISH in PHP is an implementation of the Bcrypt hash. Bcrypt is based on the Blowfish block cipher, making use of it's expensive key setup to slow the algorithm down.

If you use PHPass as in the above example and PHP >= 5.3, you will be using BCrypt.


Program binaries or files with same MD5 hash

This page has a pair of PostScript documents that have an MD5 hash collision.
This page has a pair of X.509 certificates that have an MD5 hash collision.
Wikipedia also has a pair of hexadecimal strings that are very similar and yield an  MD5 hash collision (when hashed as raw binary data).


Can a structured (text) document be effectively encrypted

What you refer to is a known-plaintext attack where part of the original text is known to the attacker. While simple encryption schemes are known to be vulnerable against such attacks modern ciphers are considered to be safe against this. With these modern ciphers all the known-plaintext allows is to verify if the decrypted result matches the original input, but it is still a brute-force attack over all possible encryption keys needed since all possible  keys are equally probable.

In other words: it might be a problem if you run your own encryption. It is not a problem if you properly use established modern encryption.


Yeah the backend can be used in your case to sign anything into your s3 bucket.

You could block cross site XMlhttprequest for /sign but why you are letting others know that you are using some backend script.
For this thing you might have to be aware of XSRF called as cross site request forgery attack that can be performed.

Specifically saying this method is not so much secure as compare to using backend to send data to aws. Also there are many ways that have been online to do cross site xhr request.

For prevention of xsrf you might have to look here too

http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
http://www.cgisecurity.com/csrf-faq.html

But i wont do your way.though its easy and good way but it has vulnerability that can be exploited.


Which type of smart card supports certificates?

From the top of my head, 2 cards that are known from having certificates:

CAC (Common Access Card)
PIV (Personal Identity verification)

However, a more broad answer would be "any smartcard that implements PKCS# 11 standard" (which would be the answer for your second question). The PKCS 11 standard determines how cryptographic tokens are accessed. For a CAC card, a library may be provided. For a PIV, you may want to take a look at the documentation NIST provides for it.

Since what you need to do is just do a security demonstration, I would go with the easy path and use a Yubikey instead. It uses the same protocol that smartcads uses (as a matter of fact, it is detected as one) and you can easily find how to manage card authentication certificates for it.


Session-storing an encryption key password

If you are caching the key, there is always going to be some risk.

That risk can be mitigated by:

Restricting the amount of time the key is kept in memory
Restricting to dynamic memory only so that it is lost on page close
Using a hardware or virtual key store to make access to the key easier but more secure. Ubikey or Windows certificate store would be examples.

Private keys MUST NEVER be stored on a server unless they are themselves encrypted with a key that only the user has (making the process rather redundant). Once a users private key is stored on a server, it can no longer be considered secure.


You are better off enforcing a length requirement, since you are already using a strong password hashing algorithm. Since the "padding" is added in the code of your site, it is not strongly protected. Even in the best case, when an attacker does not know the padding, if a user is allowed to pick a short enough password, it is conceivable that it would be cracked, revealing the padding scheme.

For complexity requirements, it is probably best to just give some instant feedback (JavaScript) on the strength of the password to the user as they choose their password. Users will balk at strictly-enforced policies (other than length, within reason), and your choice of algorithm should provide enough resistance to cracking for passwords of a reasonable length.


Take a look at this USB keyboard:

"But that's not a keyboard! That's an USB drive, silly!"

Actually, no.  It looks like a USB drive to you, but when it gets connected to a computer, it will report that it is a USB keyboard.  And the moment it is installed, it will start typing key sequences you programmed on it beforehand.  Any operating system I know automatically trusts USB keyboards and installs them as trusted input devices without requiring any user interaction the moment they are connected.

There are various payloads available for it. For example, there is one which types the keyboard input to open a shell, launches WGET to download a binary from the Internet, and runs it.


Can IT spy on you through anti-virus when using VPN?

Yes, Web Control doesn't care whether you're using a direct connection, a VPN, or a proxy server. If you want to do something and you're worried about your university seeing logs, then you better use a personal computer. You can pretty safely assume that everything you do on their laptop is available for them to scrutinize.


inherent drawbacks of browser based OTP solutions?

There are some potential additional risks from using a browser-based tool.

The main one probably being the security of the storage - where are the OTP settings stored and how secure is that.

The second being that browsers are already quite complex and so may have vulnerabilities over and above a bespoke tool.

Without a doubt, generally hardware tokens are considered more secure as they tend to be very heavily tested. Though there have been some notable failures of course and that requires recall and reissue.

Software tokens are always likely to be only as secure as the platform that hosts them so you should bear that in mind too.


When I controll EIP, how do I discover what the next steps are?

Yes, but be warned:

All function gets its parameters in the stack, or sometimes in registers. Probably you don't know, which params and where will it get. Maybe you will need a little bit play if you won't and early crash at the begin.
The return of a function is on the stack, but sometimes they are in registers. It is very sure, that the process will die after the hooked code.

If you are working on a hook, then make sure that ESP and the registers will be set back after your hook.

Maybe you can have problem if there is some like address space randomization feature, which makes the address of the function problematic to find.


What Is "Kaspersky Security Center Network Agent"?

We use Kaspersky in our network as well. Kaspersky Network Agent is the agent installed on client machines to report back to the security center (or the central point of command for your IT staff) The Agent itself is not responsible for the AV. Its simply the means to which the Endpoint manager(the AV on the system) can communicate with the Security Center server.

The agent also takes in the responsibility of installing applications remotely, managing endpoint encryption, and a few other Kaspersky features.

The reason you can't see the agent is because its a background service. Its just controlling and issuing the policies to the Endpoint Manager. Now if you can't see the endpoint manager it is possible for the IT staff to hide this with the "Self-defense" options. The IT staff where you work obviously does not want you tampering with the Endpoint manager and they would surely see the Audit arise in the Security Center if you did. For good reason though. Kaspersky will aide(not eliminate) in helping reduce your laptops attack surface and preventing possible compromise.

If you feel that only the agent is installed( and verified you don't see the signature "K" symbol in the task tray), it might be wise to call your IT department and ask if the system is being protected. Surely if they were using Kaspersky they could view the managed systems and see that your device is unprotected, if the agent is functioning and communicating properly.


Is there any point to keeping a "Verified by X" image on the page for a page secured by SSL?

Personally I completely disagree with any form of security assertion on a webpage. I'm writing a blog at the moment about exactly this.

Many financial institutions features things like "Log In Securely Here" links and pictures of padlocks dotted all around the place. A simple SSLstrip attack and the user is browsing the page over http:// yet they are logging in "securely" because, well, the page says so and there is a picture of a padlock so it must be secure.

I also agree with your point that it detracts the user's attention away from the address bar which is the only place a user should look to seek assurances about the security of their connection. Expecting them to look for and trust a jpg that says the site is secure is a bad practice. Anyone can put a padlock icon on their site and say it's secure when it isn't.


Attacks on "signatures" of the form sha256(message || secret)?

From Wikipedia:

  The alternative, appending the key using MAC = H(message ∥ key), suffers from the problem that an attacker who can find collision in the (unkeyed) hash function has a collision in the MAC (as two messages m1 and m2 yielding the same hash will provide the same start condition to the hash function before the appended key is hashed, hence the final hash will be the same).


How can an MD5-encrypted OpenPGP key be exported without entering the passphrase?

Encrypted Private Keys in OpenPGP

Generally in OpenPGP and specifically also in GnuPG, private keys can be encrypted with a symmetric key derived from a passphrase. For deriving the symmetric key (session key), a string-to-key function is used. Usually the Iterated and Salted S2K is used:

  The salt is combined with the passphrase and the resulting value is hashed repeatedly.

The other methods include a simple hash and a salted hash. The hashing algorithm can also be chosen -- while MD5 is allowed, it shouldn't be used as it is considered weak. Also the symmetric encryption algorithm can be chosen, while the defaults depend on the implementation of OpenPGP you use.

You probably fetched up information for old versions of PGP, which only used plain MD5:

  Older versions of PGP just stored a cipher algorithm octet preceding
     the secret data or a zero to indicate that the secret data was
     unencrypted.  The MD5 hash function was always used to convert the
     passphrase to a key for the specified cipher algorithm.

Exporting Encrypted Private Keys without Entering the Passphrase

If Kleopatra is able to export the private key anyway, several reasons might exist:

it exports the encrypted copy of the private key,
the passphrase for the key is stored in gpg-agent or
the passphrase is stored somewhere else (which Kleopatra doesn't, but other graphic keyring managers do, like the GNOME keyring).


I think your main problem would be to implement the Format-Preserving encryption in the database.

You could simply use AES on the field. See for example the encryption functions supported by MySQL. For a 20-byte input, aes_encrypt() output would be 32 binary characters (AES works on 16-byte blocks). You can get closer (25) with the less-secure (and deprecated) des_encrypt().
If you don't need strong encryption, MariaDB features an encode() function that may do the work, that would keep it the same length.

The main problem is that these encryption method would output binary bytes (the server would have no problem with it) but that may be undesirable for the clients (or simply for providing an output). Encoding it in base64 (33% overhead) is probably acceptable in such case.


Can a wifi provider decrypt HTTPS usind MITM without users noticing?

As a router, can I send forged certificates, and intercept requests to CA and return responses that they are valid.

Yes you could do man-in-the-middle attacks on the router. But you cannot usually do SSL intercepting without the user noticing because the browser warns about invalid certificates.

To do interception without these warnings you have to either make the user to accept your interception CA as trusted which usually means that you have access to the users system (in which case you could do much more harm). Or you have access to the private key for the specific certificate you like to mitm, or you have access to an intermediate CA signed by a CA trusted by the user. In both of these latter cases any hosts using certificate/public key pinning will still cause security errors.

Which CA's are trusted depend on the browser and OS and you can simply cause the system to trust additional CA's without user interaction or without having access to the users system. But you might try to hijack the download of Firefox which comes with its own set of trusted CA's and replace the CA's with something else. Of course if you manage this you could even simply bundle some malware to the browser or modify the browser so that it does not properly check certificates at all.


Can bad guys record phone conversations without the carrier's knowledge?

Giankun, this story by The Intercept says that it has already happened, as Steffen Ullrich said in the comments to your question. The link i provided above tells the long story about it. This second link talks about the greek incident and about another one that occurred in Italy.

There lots of articles about these incidents. Search for the names of dead engineers and results will pop up. There is also this blog entry titled "Who's murdering NSA whistleblowers?".

As you will note, officially, the mentioned institutions have no relation with the reported deaths, but the articles show that your question is already a reality.


TLS is just a protected channel between two communication peers, usually on top of TCP. It does not matter if such a peer can be either client and server or even both at the same time (but not with the same peer). And it also does not matter for the roles in the TLS handshake in which direction the TCP connection was established.

For example in FTPS the TCP connection for the data transfer can be created from client to FTP server (passive mode) or FTP server to client (active mode) whereas the TCP handshake on top of the TCP connection is always initiated by the client so that the server certificate can be used for authentication in order to protect against man in the middle, i.e. sometimes in the same direction of the TCP connection (passive) and sometimes not (active mode).

Another example is SIPS (VoIP) where a SIP device is both client (for initiating calls) and server (for receiving calls). In case of SIPS the direction of TCP connection and TLS handshake match. Authentication is usually done for both client and server (i.e. mutual) where each provides the certificate matching the device. And, if the roles switch the same certificates will be used: if A calls B then B's certificate is used as server certificate and A's as client certificate, if B calls A then A's certificate is used as server certificate and B's as client certificate. And, in case of a SIP proxy the same system can be even be both SIPS client to some servers and SIPS server to some clients at the same time.

Thus, it is no problem to use P2P architectures like SIPS together with TLS. And one can also use certificates in such a setup as long as each node has a clear address or other identifier which can be used as subject of the certificate and then checked during the certificate validation. This way a PKI can be used for a more scalable trust model compared to PSK or SRP.


Both of them will have varying times depending on iteration count:

LUKS hides this somewhat in most Linux distro installs, though it can be changed afterwards, per this Stackexchange question

Veracrypt makes setting the count trivial - use and change the "PIM" setting.


Is it still secure if a cryptographic key generated with OpenSSL while a backdoored HWRNG used?

There's no evidence that Intel's RDRAND instruction set has been backdoored, just speculation based on it being a high-profile target for such attacks, and the known nation-state capabilities of introducing subtle silicon-level backdoors into products at the supply chain level. While such a case would be incredibly unlikely to be used in a non-targeted way, and even more unlikely to affect your average user, it's still an interesting concept.

Linux's random number generator implementation (i.e. the one exposed by /dev/urandom - forget about /dev/random for now because it's irrelevant for almost every use-case) involves several key components, the most important of which for this discussion are the entropy pool, the mixing system, and the generator itself.

The entropy pool is a block of memory which has data fed into it which is expected to be highly unpredictable. The goal is to introduce enough uncertainty that it is highly infeasible for anyone to guess what the data inside the pool is. The pool does not need to be large; even a few hundred bytes is quite sufficient to be effective.

Each source of data, which might include CPU debug registers, performance counters from the chipset, timing measurements from the display driver and HID, and all sorts of other feeds, are not independently useful as random numbers for cryptography. It is only in combination that they are useful, as in total it becomes very difficult to predict the resultant state. In order to properly combine these sources of data you need a mixing function which allows a set of independently somewhat-predictable values to be coalesced into a single highly unpredictable value, without losing any of that unpredictability in the process, while also being resistant to cases where an attacker controls or knows the value of a small number of the inputs. Cryptographic hash functions are great at this - you can feed in a concatenated string and get a single fixed-length unpredictable result. This output can then be fed into the entropy pool by xor'ing it with the existing data inside it, which has the useful property that even if the attacker knows the output of a single mixing step, it tells them nothing about previous or subsequent steps and should not allow them to predict the pool contents.

The /dev/urandom implementation takes contents from the entropy pool, generates a key from them, and uses it to key a pseudorandom function (PRF) constructed from AES in CTR mode. This allows it to generate a huge amount of cryptographically useful random data (many gigabytes) from only a few hundred bits of data in the entropy pool, and do so very quickly (hundreds of megabytes per second). This alleviates the need for continuous sources of random data - even under heavy pressure to product random bits, the PRF only needs re-keying every few seconds, which gives the system time to acquire more data from entropy sources like performance counters.

This is where the concern about RDRAND comes in. The implementation within the kernel does not use the mixing function like other sources do. Instead, its output is directly xor'ed into the entropy pool. This means that a backdoor in the silicon could potentially have knowledge of the pool contents and output complimentary values which produce a predictable or known state, allowing the output of future calls to the RNG to be predicted. If you assume that such a backdoor exists, then the Linux entropy pool construction is vulnerable to such an attack.

Now keep in mind that all of this is highly theoretical. Surreptitiously introducing a silicon-level backdoor to the Intel supply chain is a fairly tall order even for nation states, but that backdoor would also need to be able to discern when to trigger the backdoor in the specific case of an RDRAND instruction execution that is part of the Linux kernel RNG and not just some random other software or driver using it, and also avoid triggering the backdoor during any unit testing (whose code may be identical to that used in the real kernel source). On top of all of that, it would also need to be able to discern the location of the Linux entropy pool in memory and perform the necessary memory reads to implement the backdoor, which is actually a fairly tall order at that level of attack implementation. TL;DR - it'd be one hell of a feat for anyone, even the NSA or GCHQ, to pull off, and I cannot possibly imagine them risking the exposure of that kind of capability by leveraging it against a mass-market product rather than only in targeted cases.

The Linux RDRAND implementation caught Linus Torvalds some flack on the mailing lists, but he steadfastly defends the approach. His argument is that in the case of such a sophisticated hardware attack like that, there are so many other (and easier) ways that the processor could expose cryptographic keys or even provide remote access to the system, and the massive performance increase is worth bypassing the mixer for. With the recent revelations of the Intel AMT vulnerabilities, and the lack of openness and accountability for IME/SMM firmware, it seems quite reasonable to expect that much easier avenues of attack would be preferred.


Risk in buying an SSL cert from a not well-known party

There is no risk of compromising the private key, because you send only the CSR which contains the public, but not the private key. But using a CA is in effect a trust delegation, as people trust your certificate because they (or the browser) trust the CA that signed the certificate. Once they notice that the CA is no longer trustworthy (like DigiNotar after it got hacked in 2011) they will remove the trust and thus they will also not trust any certificate issued by the CA any longer - which directly affects you.

If the CA itself is trusted but the reseller is just cheap, I would not worry too much. Reseller often get a huge rebate from the CA and can thus offer cheap prices if their other costs (like marketing) are small.

You should better check if the seller has high costs for services you don't need right now, but might need later - like certificate renewal or revocation. This is so called buy-in, and you must be on the lookout for this tactic almost everywhere you shop.


Can malware "upload" itself to the actual mobile base station and regain back to another phone?

Such an attack is theoretically possible, but is it likely? As always, to estimate the risk of an attack you must look at your threat model. Yours doesn't quite make sense.

You are assuming a targeted attack from a sophisticated and well resourced adversary, but that such an adversary wouldn't use a fake base station and directly target your second phone.

(To be fair, you're probably not consciously assuming an "ATP" style attack, but the attack you are imagining is too complicated and too specific for anyone else to bother with it.)


How do I protect from a PNG vulnerability on Android?

Am I overthinking the case?

Yes, you're overthinking this. The message you've received (which is a common scam) is using an image to evade keyword detection by spam filters.