Why is the password field blanked in the registration form if the validation fail?

If you're ever able to "send back" the password, through any channel, then you're not handling passwords correctly. Period.

If the password can be retained in the form via client-side caching, that's perfectly fine. Arguably still riskier than not, but certainly much safer than: (a.) sending the password over the wire (in any form) more times than necessary, and (b.) giving the server more access and time with the plaintext password than necessary.

Once a server receives a password, it should be put through whatever hashing process is required for comparison against (or insertion to) the database and then the plaintext should be immediately discarded. There's very few - close to zero - cases where any additional server-side handling of the plaintext is appropriate, and all of them increase its risk of compromise (even if only by increasing the time it's retained by the server).


Why are pins required on boot on devices with fingerprint readers?

The PIN is used to derive an encryption key, whereas the fingerprint is used only for authentication. Because the encryption key is kept in memory during runtime, it is lost after a reboot and needs to be supplied again. It is supplied via the PIN or passphrase that you are required to enter.


It would take me (and anyone with HTTP proxy) exactly 2 minutes to defeat this kind of protective measure.

The only effective protective measure for software is not to ship it to user. E.g. you can include only half of the functionality in the demo version. When user wants to upgrade to full version you take their money, give them one time link to download full version.

Or you could do part of the software as a service, depending on what it does, user can send the data to your server, and then you either perform the action or not depending if they are paying customers.


Questions about user authentication over REST API

You can take a look at JSON web token.

SSL is required!

The user submit his username and password the first time.

After verification you just send a token to the phone which will be used to verify the user and the permission on each request.

Details are available on http://jwt.io/.


A demonstration may be of help here. Let's say that there are three security clearance levels: top secret, secret, and unclassified. Let's assign our User (U1) the secret status. In this case, your (a) claim

U1 must have a higher security level than O1.

is correct, because U1 can read but not write to the file (the star property). To prohibit read access for U1 on O2, the second object, the object would require top secret level clearance.

But what about write access? A controller of 02 at the top secret level can rescind access to that object from a subject. Rescinding access would therefore prevent U1 from writing up to 02.

For more information, see: http://courses.cs.vt.edu/~cs5204/fall99/protection/harsh/


What are MITM proxies used for in enterprises?

Most of your assumptions are correct. Inspecting traffic content allows a company to look for:

malicious traffic (not just viruses)
DLP violations
it can also be for the employee's protection against externally malicious traffic, like phishing, abuse, extortion, etc.

They will know what sites you visit through other means.

Because they own the network, the machines, and the data, they have a "duty of care" to be able to protect it all, and part of that is monitoring. But it does impact the individuals.

Companies are usually required to notify people if they can inspect traffic so that the person can choose to not engage in personal activities on the network. Many companies set up a "public" wifi so employees can connect to that, or permit the use of personal phones so people can use the cellular networks for personal business.

It sounds like you are shocked by finding this out and this might be a discussion you need to have with your IT department, HR, and/or your DPO (if applicable). You might have been given notification but you might not have known what the notification meant.


How does the NSA restrict public access to cryptography?

This quote is quite misleading in several ways. Let's recall some facts:

Bruce Schneier writes from an American (as in "USA") point of view. This is rather clear: when someone says "national" without specifying what nation he is talking of, then chances are that he means the USA.
USA, like many other countries, have export regulations for cryptographic material; they also have other laws regulating usage, import, publication... in a number of more or less complex cases. See this site for a comprehensive survey of cryptographic laws around the World. Take note that these regulations evolve at a fast pace, just like the technology that they are trying to regulate; 20 years are a long time.
US export regulations are controlled by the Export Administration Regulations, an emanation from the Department of Commerce, but in 1994 the relevant administration was ITAR, linked to the Department of State, with inputs from the Department of Defense during the review and approval process.
In 1994, there was an ongoing criminal investigation with regards to a supposed unauthorized export of "munitions", namely the source code for PGP. In order to work around the export regulations, the source code of PGP was printed as a book (because export of books from the USA is not restricted), and meant for automatic scanning once beyond the USA boundaries (so this was only technically a book; it would be fairer to call it a "floppy disk made out of paper"). It is actually unknown whether the export was really done with the book and a scanner, or simply with a floppy disk or network, using the "book" as a plausible deniability token (since the book exists, it could have been used, and therefore the existence of the source code in non-US countries does not automatically imply that it was exported through any other, regulated means). Anyway, the case was dropped a few years later.
The NSA is one of the multiple intelligence agencies of the USA, specially dedicated to communications, in both offensive and defensive roles. This means that the NSA is likely to be involved on cryptography questions, when it comes to breaking other people's systems but also, for US own usages (government and business), promoting encryption systems that other people won't be able to break. In the latter role, standards are established by NIST (which depends from the Department of Commerce) with inputs from NSA (which comes from the Department of Defense) without any formal subservience.

The rest is mostly speculations. The quote from Applied Cryptography translates Schneier's point of view, or, more accurately, what was his point of view back in 1994. These speculations include the singling out of "the NSA" as an all-powerful puppet master, able to curb the other parts of the US Federal administration to its will; that the NSA wants to spy on American people (that one is true, although their mandate is for targeted individuals) and will thus want to kill strong cryptography altogether (that's the speculative part: it completely ignores the other role of NSA as promoter of strong cryptography); that everything which happens in the field of cryptography is (or was) a direct result of a struggle between the arch villain Darth NSA, and a bunch of disorderly youngsters fighting for their freedom (of speech). This is, at best, an atrociously simplistic cliché. It also makes the highly implausible assumption that a huge administrative structure like the NSA is both competent and structurally efficient.

Like most defense-related organizations which have lived throughout the Cold War, the NSA and the myriad of other similar agencies has long had a structural tendency to think of "the Enemy" as definitely Red and Siberian. However, the field has changed. In particular, War is now much more a question of economy and commerce than soldiers and nuclear warheads. Classic spying involves a fake plumber with big ears in an embassy; modern spying will more use a fake intern at some big business. This is a tragic turn of events that established intelligence agencies find hard to live: they are no longer spearheading the spying effort. Their playground has been stolen from them, and has shifted to private corporations who now wage that war between themselves.

This forces intelligence agencies to reevaluate their goals and methods, which is easier said than done. To some extent they found some relief in the definition of new "normal" enemies (albeit with less communism, but longer beards and a sunnier tan). But they still have to tilt toward their "defensive" role. In the field of cryptography, this can be seen by comparing DES with AES. The old encryption standard was designed by IBM. NSA was involved, and, from what was said afterwards (in particular by Don Coppersmith), we can conclude that the NSA inputs influenced the design in two ways:

The (effective) key length was shortened, from an initial 64 bits to 56 bits (which mechanically implies a lower resistance to exhaustive search).
The DES "S-boxes" were strengthened against differential cryptanalysis. More accurately, both IBM and NSA has independently discovered that kind of cryptanalytic method, and they worked together to make strong S-boxes; NSA furthermore "convinced" IBM not to publish the method (which was ultimately rediscovered by Biham and Shamir in the 1980s, and then published).

These design influences are the mark of a self-concious leader: the NSA of the 1970s knew (or at least assumed) that it was more powerful than the rest of the World, both in computing power (they thought they could go through 256 possible keys faster than anybody else) and in mathematics (hence the ban on publication of differential cryptanalysis). They still mixed in both offensive weakening (reduction of key length) and defensive strengthening (improved S-boxes), thereby fulfilling their dual mandate.

Such advances could not last for long, especially since private business finally decided to embrace computers. Even talking only raw money: current NSA budget is estimated around 10 billions of dollars, a hefty sum; but Apple's cash reserve are up to 160 billions (as of early 2014). Back in the late 1990s, US intelligence agencies (including NSA) admitted that they could no longer expect to be in the lead, thus dooming the strategy of enforcing "slightly weak" algorithms. Instead, they went for the design a new encryption algorithm which was so strong that nobody would be able to break it; not them, but nobody else either. This was the AES. With such goals they could even afford an open, international competition, and select an algorithm designed by foreigners ("reasonable" foreigners, mind you; preferably westerners from a non-controversial country, in this case Belgium).

From all this, we can conclude that the NSA is not really working to prevent "the public" from accessing "secure cryptography". Instead, they are working hard to ensure that:

the "good" people (US businesses) have access to strong cryptography that the "bad" people (their non-US competitors) won't be able to break;
they can keep track of all cryptography products that are in use, so that they can at least know whether any given algorithm can be recommended for "good" people use;
they still get enough legal weapons to trigger search warrants, assets freezing or other restrictions on people that they really don't like.

NSA also realized that in a given security system, cryptography is often the strongest part, not the weakest, and concentrating on buffer overflow exploits and concealed backdoors was much more likely to yield tangible results than trying to enforce weak crypto everywhere. In particular, the Internet quite kills any hope of effectiveness for an import or export embargo.


How to sniff traffic on my wireless network?

Wireshark or tcpdump would both be useful if you want to dump packets going across the network all you need is to put an interface into promiscuous mode and you should be able to see packets flying across your network. There are lots of tutorials on using wireshark and tcpdump in the interweb.

UPDATE:

monitoring outgoing network traffic this question also appears to address what you are asking with regards to tools for examining network traffic.


Is PCI SAQ A or A-EP applicable for my use case?

Short version:

You seem to be A-EP You seem to be A, based on the specific products referenced, but you should ask your processor(s) to be sure.

If by "Amazon Payments JavaScript widget" you mean Amazon Express Checkout, then you're SAQ A-EP, because "elements of the payment page originate from the merchant website".

Amazon Payments "Login and Pay" is jut a button that takes the processors site, and the entire payment is carried out on the processors site, so technically there are no "elements of the payment page (that) originate from the merchant website" - the payment page is all on Amazon, none on your site.  So that should also be SAQ A, although it would be really nice if Amazon put this in their FAQ.

Mind you, the distinction between a link that sends customers to the processors site and a link that cites an iframe on the processors site and a link that uses direct post or javascript requests to send card data to the processors site are, in security terms, completely equivalent.  In all cases, an attacker who compromises the merchant's web server can affect where the customer sends their card data.  The only significant difference is that the customer can see the processor's URL in their address bar with something like "Login and Pay", and we assume people check that and know not to perform Amazon payments with aamazon.ru, even if it has a valid certificate.

Or - in short - if this is confusing to you, it's because it's confusing.  Again, best to ask your processor.  They're supposed to know better.

If by "Stripe Checkout widget" you mean Checkout, then you're SAQ A-EP, because "elements of the payment page originate from the merchant website."

According to Stripe, even though Checkout is a JavaScript widget "it already rests inside an iframe controlled by Stripe, you can continue to fill out SAQ A." (emphasis mine)

You would only seem to be SAQ A because all your checkout forms were hosted by the processors and your customers were directed to them before checkout or via an iframe .

Long version:

The key distinction here is found in page iii of the SAQ A:

  The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s)

If your processors all get invoked via an iframe, then you probably meet this requirement.  But if their "javascript widget" or "checkout widget" are served from your servers, then you fall into SAQ A-EP instead.  Your processors, of course, should be able to tell which they are.

The fact that the word "Javascript widget" shows up here suggests to me you're A-EP, but I'm not familiar enough with Amazon or Stripe's offerings to really know.  And, honestly, you're not really expected to know the difference - they are.

The full set of expectations for a SAQ A merchant to meet are as follows:

  SAQ A merchants may be either e-commerce or mail/telephone-order merchants (card-not-present), and do not store, process, or transmit any cardholder data in electronic format on their systems or premises.

  SAQ A merchants confirm that, for this payment channel:

  Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
  All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers;
  Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;
  Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely
  on a third party(s) to handle all these functions;
  Your company has confirmed that all third party(s) handling acceptance, storage, processing, and/or transmission of cardholder
  data are PCI DSS compliant; and
  Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.

  Additionally, for e-commerce channels:

  The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated
  service provider(s).


Disable weak cipher for Google Cloud App engine custom domain website

I found out that, if the App Engine uses a custom domain, it is possible to disable it for the custom domain. To do this you have to contact GCP and make a request with them. The whole process took them about 3 weeks to disable it.


Is originating number tied to an SMS from a mobile phone?

Phones don't even know their phone number. Sure, there is a number field in the SIM card that can be updated remotely by the carrier, but most importantly there is no guarantee that field is even set or is set to the correct number. Phones identify themselves to the network using the IMSI of the SIM card (and proves that it indeed is the card associated to that IMSI by crypto based on the card's symmetric KI key) and from there use the random TMSIs assigned to them by the network.

The numbers are added by the mobile network infrastructure down the line. You can very well have multiple numbers tied to a single SIM card and phone, and you can theoretically change your number in a matter of seconds (though in reality most mobile network infrastructure is legacy crap that won't allow it, but technically there is nothing preventing this from happening if carriers were using decent software).


Do the Owncloud clients use encryption when transferring files to and from the server?

By design, OwnCloud sits on top of a web server. You can configure SSL on the web server as you would any website or web application.

This link you provide you enough information to get you started.


Understanding the behaviour of existing eavesdropping techniques

There is no legitimate way for an unauthorized eavesdropper to access those specific packets.  So let's break it down:

Make it legitimate. Eve* could ask Alice or Bob for those packets.
Authorize it.  Eve could be a law enforcement officer, and request the network provider to deliver copies of those packets.
Be less specific.  If Eve is a thief who just wants to steal from anyone, there's no reason she has to hack a network in L.A.; she could hack one closer to home where she has physical access.

If Eve is prepared to engage in criminal activity, she would then have to hack into Alice and Bob's network, and gain access to one of the devices on one of the subnets carrying their traffic.  Your specific example of 192.168.1.0/16 may be a problem for her, as that is a non-routable address range, commonly managed by home routers behind a NATting firewall (in other words, 192.168.. is not a unique address, it's shared by millions of home networks.)  But she can find their network through some other means.  One way is via an email embedded with an HTML image, which has to "phone home" to retrieve the image when the message is read.  That will give her the routable ("outside") address of her firewall.

How she hacks into their network is as broad a question as "how to hack?" and can't really be answered.  But let's say she gains access into the network by portscanning their firewall, and finding a hole opened by some irresponsible home automation device that uses UPnP.  Let's say she gained access via an insecure thermostat's web interface.

If sniffing network packets is her ultimate goal, she'll need to access a machine capable of running packet capture software.  This may require using a machine more capable than the thermostat she hacked into.  So she may need to 'pivot' to another machine inside the victim's network to gain access to a PC.  Once the thermostat is acting as a relay, she searches the network looking for other machines, and finds an unpatched PC.  She takes it over, and from the victim PC, she establishes a 'reverse shell' back to her computer, giving her command access to it.  On this remote PC, she'll install a packet capture program like tshark, and run it for a while.  This will produce a capture file without the graphical interface.  After capturing packets, she'll copy the packet trace file back to her computer and run a tool like Wireshark to view and analyze the contents.

* The set of placeholder names often used in cryptographic protocol analysis includes Alice and Bob, who want to communicate with each other; Eve, a passive attacker who can eavesdrop but cannot tamper with their communications; and Mallory, an active attacker who can both listen to and tamper with their communications.  You may find it useful to understand and use these common names.


Do I REALLY need to change my LastPass password?

No, a 30+ random character password is safe
If your password is 30+ random characters, the number of possible passwords is well beyond 95^30, which is 2.14e59.
The Oclhashcrack page gives a sample crack rate for SHA256 of 16,904 Mh/s. So lets assume the "budget equal to the world GDP" would allow for a million of these computers to perform the cracking. (We are ignoring the 10,000 rounds for simplicity).
The computer can guess 16 billion hashes per second times 1 million computers. This would equal about 1.6e16 guesses per second. Thus it would still take 1.3e43 seconds which is equal to 3.1 e25 times the age of the universe. Multiply the number of computers by 10, and you drop to 3.1e24 times the age of the universe.
So finally consider that the 10,000 rounds means that the hash calculation would be reduced by 10,000. Further consider that the hashes are randomly salted. This means that an attack has to be targeted on a specific hash.
What about other attack possibilities?
If we consider that attackers had access to the Lastpass network, the attackers are more likely to get the plaintext of a 30+ random character password by intercepting it in plaintext when you log into the website. Lastpass hasn't given any indication that this has happened, but this would be a realistic reason to change your password.


Where to disclose a zero day vulnerability

You should request a CVE ID from MITRE (https://cve.mitre.org/cve/request_id.html), which is the responsible CNA for this.

You can then disclose it on security mailing lists like Bugtraq or FullDisclosure. Security magazines and news sites might also be interested in the vulnerability. You can contact them directly and ask if they are interested to publish the vulnerability. Though they likely follow Bugtraq and FullDisclosure anyways.


Does a binary executable have to have some critical plain-text components?

Ultimately, the CPU runs the code. And the CPU expects instructions in "clear text". You could envision some application code where a small initial part of the executable first decrypts the rest of the code, but this has several issues:

This forces all the code to go to RAM instead of staying on disk and be loaded on-demand, implying a higher RAM consumption and longer start times.
That "decryption" routine must, necessarily, not be encrypted.
The decryption routine knows everything needed to decrypt the rest of the code, so it can be decompiled and emulated by the attacker; it is not really "decryption" since there is no key (or, equivalently, the key is embedded in the routine, which the attacker has under his hands).

Experimentally, this kind of encryption does not hinder attackers much, so the general wisdom is that it is "not worth the effort". Unless you are in a very specific scenario where the "attacker" is a mindless automaton which may be fooled by these hide-and-seek methods -- that's the case of virus, where the "attacker" is the antivirus software.

Really encrypted code is possible if the CPU is doing the decryption itself, internally, with some key management. That's what happens in a PS3 console, for instance.


Basis for "trusting" third party code and services

I was recently employed for an organization that used third party software. Here is our thought process.

There is strength in numbers. Third party software that is A) open source, B) has a dedicated and knowledgeable security team, C) has a responsible disclosure policy, and D) is widely used by thousands of customers is better than anything our organization could ever put out.
There is strength in doing the legwork. I was assigned to every module of this third party software, and I did a full review of it before allowing it to be added to our infrastructure. And if we found a vulnerability, we utilized the responsible disclosure program to make the software better.
There is strength in updating. We subscribed to vendor alerts to make sure that if someone else found something, we were able to respond to the incident and protect our infrastructure.

Of course, there are also weaknesses to this approach:

There is weakness in homogeneous software. If a large exploit came out, there's a high chance someone found our site and attempted a point and shoot exploit.
There is weakness in numbers. We did a full review, but did the other thousands of people using it? Probably not.
There is weakness in volunteer work. If something happened, there was no vendor rep to talk to. We had to A) retrace the problem, and B) fix it before we got hit.
There is weakness in quality control. Open source is all about community contribution. However, the first law of humans is that humans are stupid, and no language is stupid proof. Especially PHP, which is what the software was written in.

As with all security policies, you must be risk aware, and minimize risk where you can. The only way to reduce your risk to zero is to write on wax tablets by candle-light.


Essentially, you add your Burp certificate to your trusted certificates list. This can be done by loading Burp, proxying a browser through it, and then visiting http://burp/. You should see a page which has a few links across the top, one of which is "CA Certificate". Clicking this will give you a download of a file called "cacert.der".

You can then install this either for a specific browser, or for the whole system - I suggest using a specific browser or browser profile for Burp, but it's up to the individual user. For Firefox, the certificate can be installed by going to Options->Advanced->View Certificates, then "import". For Windows, double clicking the certificate will allow you to install it. There is also an automatic configuration tool for Firefox called "Plug-n-hack", available from the same Burp loaded page, which automatically installs the certificate and configures the proxy settings.


Why are card associations launching RFID enabled payment cards despite of their being unsecure?

Many people use cars on a daily basis, even with the number of deaths on roads worldwide. So why would everyday people want to use them?

The reason why I ask that question at the start is because it will get you into the mindset of Information Security. Nothing is secure everywhere, all the time. The same applies to cars, they are mechanical devices that have physical flaws, and as time progresses, virtual ones as well.

"Tap" payment schemes came about because of the wear issues associated with "Chip and PIN" technology. Due to the shear number of cards being put into a card reader at a retailer, the cards and machines become worn out. This is not only because of the physical contact required, but also dust and dirt which is just an everyday thing. "Tap" or RFID payment schemes overcome this because there is a belief that if small purchases are done with RFID, the cards and machines will last much longer. You may wish to consult your credit card company for their analysis on this topic.

At least my understanding of the current system, while it is certainly correct to say the system is "broken", there are certain features that mitigate risks.

The first is a payment limit. Many cards limit how much can be purchased by RFID or contactless transfer. As I bring up the previous point of small purchases, there is huge risk involved for everyone with large transactions (thousands of dollars). I'm aware that my card with a recent contactless terminal will not allow for a transaction over $100 to be processed, it must be done with the Chip and PIN.

The second is that the "keys" associated with transactions expire. I've seen various bits of information where some state that it's possible to clone a rfid card, but you would be unable to use it for another transaction. Other sources mention the fact that the clone will work until the true user makes another payment. Regardless of what the case might be, there doesn't seem to be any clear innovation coming down the tubes for a while. The easiest way would be to still provide a PIN, but again, removes the end-user convenience, and you might as well just use the Chip and PIN technology.

To be fair, the likelihood of someone bringing a crafted device to capture RFID payments is fairly small. Because of the close proximity involved, one would either have to physically take possession of the card, or bring such a large antenna (and/or power supply) making such a thing impractical.


My company name is being used in email address to send fake job offers to random people. How do i stop this

If your server has its mail relays open, it might be used to send spam emails. For more information take a look:

https://uk.godaddy.com/help/testing-your-server-for-open-relays-8495


Has anyone achieved PCI compliance on AWS?

Amazon does have a Type II SAS 70 report. Requesting a detailed copy of that should show all the controls they have in place. It may that people are asking Amazon the wrong questions. As a quick note, the SAS 70 testing in the future will be referred to as an SOC -- one of those accounting industry quirks.

Especially with an Amazon-sized company, one looks at the report, sees that it is reasonable, and declares that they have done due-diligence. In very vague terms, Amazon and their PCI auditor then have some sort of fiduciary duty in the case of a whoopsie-daisy on their part.

See also:

http://securosis.com/blog/what-amazon-awss-pci-compliance-means-to-you
http://aws.amazon.com/security/pci-dss-level-1-compliance-faqs

Update: The relevant control objective for you as a client is this: 2.4 Hosting providers must protect
each entity’s hosted environment and
data. These providers must meet
specific requirements as detailed in
Appendix A: “PCI DSS Applicability for
Hosting Providers.”

At least in my interpretation, Amazon principally has to deal with the four controls specified in A.1. There are many others that don't matter, and some that do. I don't know what your auditor is able to get, but as I understand without documentation in front of me: Amazon has passed without remark. That means they have been independently reviewed to meet all those objectives. With that in mind, the rest of the burden is on your company to meet everything else that's relevant to what is inside the instance.

Auditors aren't always right. You may find it worthwhile to engage another auditor. You may find I'm wrong (though I'm confident I've got this). At least you don't have this: https://serverfault.com/questions/293217/our-security-auditor-is-an-idiot-how-do-i-give-him-the-information-he-wants


Is that possible? A router with arpspoof from factory

If you Google the log entry about arpspoofing you get a hit on the probable manufacture which is Huawei.  They hold a patent to prevent arpspoofing link to patent and their products are discussed in several articles as a solution to same.  TomTop appears to be a wholesale marketer of Chinese products including Huawei routers.

It appears you have a poorly written/translated standard log entry to a good feature.


Could a third party access my system - particularly browsing history?

Your question is quite vague, but here are some pointers that might be of help:

Email attachments are a common method for putting malicious files on your machine, along with drive-by downloads.
It's more common to be infected by unknown mail senders or on dubious and unknown websites than by trusted third-parties (except maybe for social network malware which necessarily spreads through your connections)
You can still get infected by trusted parties or on trusted websites, if they have been infected themselves
From your question I take it that you're more worried about your colleague spying on you. If your colleague is not a trained computer security engineer or hasn't done any hacking in his life you're most likely safe! Indeed I don't think that Excel files are commonly used for extracting browser history (if you wanted that information it'd probably be easier to make you install a malicious browser extension)
You must still open these files for them to have any effect. This is in opposition with many Web attacks that run local scripts on your machine simply because you visited the page.
App sandboxing is starting to appear on all major desktop platforms, though not fully deployed yet. If you opened a malicious file with an unsandboxed app, and that file was not detected as malicious by the app or your antivirus, virtually anything could happen to your data and the other apps you use.
With a sandboxed Office app the damage would very likely be contained to your Office instance and would not have any further consequences. I've heard that nowadays you can run Office files in "Protected View", which only allows you to read them but blocks most potential malware.


Non-repudiation in Exchange/Outlook without Digital Signatures

Unless there is some special configuration I'm not familiar with:

Joe user. There is an Edit function, hiding right there under Other Actions (in Outlook 2007, at least...). Note you can only see this when you open it in full message view, and not in the preview pane (as I usually read it...). Note also that this is not available via OWA.
It may be possible to configure Exchange mailboxes to prevent that, but I'm not familiar with such a configuration (and no Exchange handy right now to check, sorry).
Re edit: It's a good question, what parts can be modified - subject/body/attachments are easy. Recipients and timestamps are not enabled by the Outlook UI, so at least JoeUser won't be piddling with those fields so easily... However, I'm sure it is possible to modify these, using other tools (or directly editing the file), but I'm not familiar with that. Also note the addition on the next point...
Outlook! :)
On the other hand, I have not researched deeply into the file formats or forensics - it is possible that outlook tracks changes to received messages, inside the file.
Also, note that I assume we're talking about received messages, not sent - it is trivial to fake any kind of claimed sent message, without actually sending it.
Besides the previous, note that if the email is not signed it is simple to send yourself a fake email message, that claims to be from any other user you want. At that point, of course, you can forge any part of the email you want. (This does depend, however, on your Exchange configuration - by default, it is possible to send near-arbitrary SMTP messages, though this can of course be changed, as it should be).
It cannot - in neither direction. Excepting, perhaps, a strict backup regime. 'Course, that would still be a steaming pile of work, to pull up the exact messages, and prove that it was the originally received message - this could probably only be done right if the backups were set correctly in the first place (i.e. backup the message as received, and not just what the user does in his inbox).
Also, I am not including here any form of behavioral forensics...

But there is a reason that digital signatures are required.


I want know if a file with php code but without extension name could be exploted?

Yes
The presence of #!/usr/bin/env php as the first line means that this is meant to be used from a shell context - not from the web.  When executing from the command line with a line like the above, the extension doesn't matter.  So yes, this can be exploited in an attack.
If you found a file like this on your server and you didn't put it there, I would assume your server is compromised and the file is being actively used by your attacker.  Nuke it from orbit.  This is very different from the sort of malicious PHP scripts you normally see (apparently a hacker decided to build their payload on top of Yii?), but that doesn't change the facts or my advice.
It's worth pointing out that extensions are not really very important.  Windows makes them more important than they need to be, but especially in *nix style systems, the extension is rarely important to the underlying system.  Even in a web-server context a PHP file without a PHP extension might get executed as PHP, depending on the server configuration.  It would take a non-default and less-than-ideal server configuration, but it is entirely possible and not even hard to do.  Not only that, but (h/t Ghedipunk) the application executing for the web server can further invoke shell commands or do anything else it wants.  As a result an attacker with remote-code-execution abilities on your server can certainly execute code wherever they want, however they want, regardless of extension.


Keybase.io provides a directory service that allows looking up public keys for accounts on other services that don't themselves support PGP, and whose account types are not recognized as UIDs on PGP.

For example, if I want to know the PGP key for a certain Twitter account, I can ask the keybase directory, which will respond with a text record that contains a phrase indicating this is a keybind, a Twitter handle and a key ID, as well as a link to a tweet that contains a signature over this data.

This is similar to the way UIDs are attached to PGP keys -- the master key signs a specially formatted message that contains the UID to be bound to the key. The main differences are that the binding is stored externally to the key (because there is no standard for Twitter handle UIDs), and that the signature is stored inside Twitter to provide verification that the owner of the Twitter account is really the key holder (where normal UIDs are signed by others).

This way, I can send a message to a Twitter user through an encrypted channel, although there is no integration into the Twitter service itself.

Because they allow direct messages of up to 10.000 characters, sending a PGP encrypted message through Twitter is certainly possible.

This is only good for sending messages to "the owner of an account" though, as no further verification is done. It could theoretically be attacked through Twitter itself altering the tweet so it matches an attacker's key, although the signature contained in the tweet is public, so it could be archived by third parties and manipulation thus detected.

The same goes for Github and the other services handled by Keybase.


OS detection goes a lot further, using all kind of data of the IP and TCP headers fields. If you're into reading, "Silence on the Wire" by Michal Zalewski addresses a lot on this topic.


How to explain to a customer that spamfilters don't catch everything

Your answer is pretty OK, but you could explain the ongoing "game" between spammers and spamfilters a bit more. This makes it understandable why some spam always will find its way to the customer.

Spam filters try to catch all mail that is spam.

Spammers try to create mails that are trusted not to be spam - both by spam filters and by humans.

For spammers, this comes down to creating mails that...

can pass spam filters;
when arrived in the inbox look like legit email so the user opens it;
and then is interesting enough so users click on the link inside to buy something or have malware installed.

Spammers buy spam filters, and test their new spam tactics to see if their mail passes the filter. If the mail passes, they are one step ahead. Then they go out in the wild, send out millions of mails, effectively showing their new tactic. The spam-filter makers notice, and they update their filter. This is an ongoing game. It's similar in the virus industry.

When you see spam that has no links or attachments, it is probably spam to poison filters, to confuse filters, to make it easier to fool them later on.


Using only their username to generate the GUID is not sufficient, how about adding a time stamp to it?

There should be a time limit to which the user has to click the link. The link should also expire upon account activation, especially if they are required to set a password upon account activation.

What if I am able to obtain the activation link, is the four digit code protected by some sort of rate limiting? This in order to prevent the 10000 requests to guess the four digit ID.


HIPAA compliance: how much does it matter?

All the comments posted before this are correct - unless this is a healthcare application, it probably shouldn't make a difference. The statement you're talking about is probably just to help prospective customers choose one service over another.

Also, if this is any large organization, it's highly likely that they're already auditing their infrastructure and I'd even dare say a larger company might pass an HIPAA compliance audit.

tl;dr: It doesn't matter unless you're dealing with patient's data


DDOS protection for instant messenger server

The problem with a Ddos attack is that you need to intercept/filter the traffic before it reaches the destination (your IM server). This means you will indeed need a service similar to cloudfare or increase your capacity. There is no cheap way to do this I'm afraid.


What are a few good analogies to describe the benefits of a strong security program?

Fine, I'll just quote Krag Brotby:

To successfully navigate an airplane or a security department to its destination, the necessary information includes

Objective (or destination)
Current location (relative to the
destination)
Direction (heading toward the
destination)
Speed (how long to reach the
destination)

For the pilot, or security manager, it is also necessary to have information regarding

Intervening obstacles (constraints
that may require a change of course)
Operational health/malfunctions
(knowing whether the equipment is
working properly)
Cost/effectiveness (affordability)

There are essentially three fundamentally different kinds of information required
for managing and operating an aircraft—or a security program. They are

Navigation (Strategic, Directional):

  For aircraft, this is the exclusive
  purview of a central set of
  instruments concerned with information
  about location, heading, and distance
  to the destination. This is the
  “linkage” to business objectives— that
  is, steering the ship to the
  destination that meets the business
  objectives of operating an airline. It
  is analogous to the requirement for
  setting objectives consistent with the
  business goals for an information
  security program and then developing
  metrics to provide the same
  information in terms of heading to the
  destination as well as information on
  current location.

Program Management (Tactical, Administrative):

  For our airplane analogy, this is the
  information required to manage the
  actual flying, which includes aircraft
  heading, altitude, speed and so forth,
  which is provided by the main
  instrumentation located directly in
  front of the pilot. For managing an
  airplane or an information security
  program, this information must be
  real-time or near real-time. It is the
  feedback that allows effective
  day-to-day management and
  administration while maintaining a
  heading that will achieve the
  destination.

Operational (Technical, Procedural):

  On the typical aircraft dashboard
  (called the instrument panel),
  technical information regarding the
  operation of the machinery is off to
  one side and referenced occasionally
  for assurance that the systems are
  operating in the “green” and that
  there are adequate resources such as
  fuel. This information is of no value
  in determining direction or flight
  management or whether the destination
  will be reached except to the extent
  that failure of the power plant can
  inform us that we are not capable of
  reaching the destination.

While navigation and administration are the main security management components,
they are dependent on higher-level strategic decisions about the underlying
mission of the “flight.” The oft-mentioned notion of strategic alignment therefore
is achieved when the operation of the “flight,” or the security program, serves a
higher-level organizational purpose such as operating an airline—in other words,
when the information security program provides the elements essential to the successful
operation of the organization.

The operational component of metrics from a technical perspective are available
and commonly deployed. Operational metrics at the physical and process levels are
more scarce and less automated. The components that are poorly addressed if at all
are navigation and management.


You can check your applicationss vulnerabilities here (for example): cvedetails

or in the NIST's VDB

If you found some vulns, then you can test with some penetration testing tools. Most of time you can easily find an (if it exist) exploit for vulnerability in MetaSploit Database or in Google.

And for other question:
(RedHat)JBoss Web and (Apache)Tomcat doesn't same thing.

  Both JBoss and Tomcat are Java servlet application servers, but JBoss
  is a whole lot more. The substantial difference between the two is
  that JBoss provides a full Java Enterprise Edition (JEE) stack,
  including Enterprise JavaBeans and many other technologies that are
  useful for developers working on enterprise Java applications. Tomcat
  is much more limited. One way to think of it is that JBoss is a JEE
  stack that includes a servlet container and web server, whereas
  Tomcat, for the most part, is a servlet container and web server.

You can read more here

So no, both of them has different vulnerabilities.

More related information:
Most of time the vendors of software (if they notice vulns) will announce the issue after fix-patch release. If you working with mostly JBoss, then you should subscribe to RedHat's security newsletters. Its important to take care of security, I think this is the (mostly) fastest way to keep up-to-date my knowledges about vulnerabilities.

(English is not my mother tongue; please excuse any errors on my part.)


If you have a VPS the administrator of the underlying computer system can easily do snapshots and you cannot prevent this from inside the VPS. Similar you cannot prevent snapshots of a process by somebody having administrative access to the underlying operating system.

The only way to protect sensitive data inside a process/VM is to obfuscate them in order to make it harder to extract information from the snapshot. Better yet don't even have any sensitive data inside the process/VM, that is do your sensitive computations on a system where only you have control like done with Cloudflare Keyless SSL. Or use hardware where nobody except you have access, but even in this case somebody might have tampered with the hardware or it might backdoors inside by design.


How to get vulnerabilites by product name and version

Vulnerability Management tools are designed to do this very function. They usually are able to scan devices and lookup versions against known patch levels as well as CVEs.

There are a great many to choose from with a wide range of features.

The most crucial sources to check beside the CVE database are:

Exploit-DB
Metasploit exploit repository

There are also a number of tools that can take a csv file of product names and versions and look them up in these sources (or you can make your own).


Is there a way to block all TOR traffic incident on my public servers?

See I want to ban the Tor network from my service from the official Tor documentation.

The Tor project provides a list with IPs of all the exit nodes that can access your service, use query string parameters to tell it the IP and port of your service, example : https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8&port=443.

You can then loop through the results, split them each newline, ignore lines starting with "#" and finally adding a -J DROP IPtables action to each one of them or using an IPset which would give you better performance with such a large number of hosts, something like this should do the trick :

ipset -N tor iphash # create a new set named "tor"

# get the list, don't forget to put your service's IP in the query string
curl -s https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8 | sed '/^#/d' | while read IP
do
  # add each IP address to the set, silencing the warnings for IPs that have already been added
  ipset -q -A tor $IP
done

iptables -A INPUT -m set --match-set tor src -j DROP # block any IP in this set in IPtables

(source)

They also provide a DNS based list but it's still in experimental stage so I suggest you stick with the first option, it's also easier to work with.


How secure is a partial 64bit hash of a SHA1 160bit hash?

The attack described by Marc Stevens, and all other known attacks on SHA-1 as well, are about collisions. Finding a collision is about finding two distinct sequences of bits m and m' such that both hash to the same value.

Collisions are irrelevant to the use of SHA-1 for verification. When using SHA-1 for verifying some data, there is a hash value v, and the attacker's goal is to find a bit sequence m (e.g., a password, if we are talking about verifying passwords) such that m hashes to v. This is called a preimage and it is not the same animal at all as collisions. For all we know, SHA-1's resistance to preimages is as good as new.

Let's put some numbers on it. For a hash function with n bits of output, a collision can be found with average cost 2n/2 evaluations of the hash function (this is related to the so-called birthday paradox) so this would amount to about 280 calls to SHA-1 for the full function. This kind of attack is completely generic, it works with all hash functions; Stevens' attack is considered a break because it does better, down to an estimated cost of 261 evaluations of the function: half a million times faster than the generic attack, but still quite expensive (261 is about 2 billions of billions). If you truncate the output to 64 bits then the generic attack cost is down to 232 and a PC will be able to find a collision in a few minutes. Fortunately, as I said above, collisions don't impact the use of the hash function for verification, since that use relies on resistance to preimages.

For preimages, a generic attack on hash function is called "get lucky": try random input sequences m until one is found that matches the target output. For a hash function with an output of n bits, this has average cost 2n. For the full SHA-1, this leads to 2160 which is very far in the unfeasible realm (quite beyond the "sci-fi feasible", even). If you truncate the SHA-1 output to 64 bits, then that cost goes down to 264, which is technologically feasible, but will be expensive. Let's estimate the cost: a good GPU costing a few hundreds of dollars will go through about 2 billions of SHA-1 computations per second, let's say 231 to make computations easy; so that GPU will need about 233 seconds to run the preimage attack (because 264 = 233*231). 233 seconds, that's 272 years... If you put 3000 such GPU to the task (so that's a million dollar cost for the hardware alone), it will take about one month to find a 64-bit preimage.

FPGA might lower the hardware cost, but will increase development costs a lot, because that's no longer a matter of putting together some off-the-shelf PC. A practical attacker will rent GPU time from big cloud provider such as Amazon EC2 (their "CG1 instances" are what the attacker would use in this case).

Therefore, for many purposes where what the hash/verification system protects in not too expensive in itself, truncating the SHA-1 output to 64 bits will not imply an actual security vulnerability.

Now the important notes:

All of the above assumes that SHA-1 truncated to 64 bits (let's call it SHA-1/64) is as good against preimages as can be expected from a "perfect" hash function, and as SHA-1 itself seems to be with its full 160 bits. It can be shown that SHA-1/64 cannot be too weak against preimages, because a very fast attack against SHA-1/64 could be turned into an attack against the full SHA-1 which would be faster than 2160 (not fast, but faster, which would be enough for an academic paper). No such attack is known, so it can be assumed that SHA-1/64 is probably resistant to preimage up to cost 264.
If you are hashing passwords then you are doing it wrong. Password hashing has some special needs, because passwords are inherently weak (humans accept to remember them and to type them, so they cannot be strong). When dealing with passwords, the biggest vulnerability is the password itself, not the hashing function. SHA-1/64, or SHA-1, are by themselves very poor, because they are very fast, and unsalted (which allows for precomputations and parallel attacks). Please read this answer which will tell you how password hashing should be done.

(If you are hashing passwords then the answer to your question "how many operations would it require ?" will be the same for SHA-1/64 and for the full SHA-1, i.e.: about one billion. Because user-chosen passwords rarely exceed 30 bits of entropy. A good GPU will need less than a second to do that...)


Notifications (RSS or mailing list) of CVE with high scores for Windows and Red Hat?

CVE Details allows you to create a customized RSS feed with certain CVSS scores.  : http://www.cvedetails.com/vulnerability-feeds-form.php

However, I'm not sure if there's a way to filter out only Windows & Red Hat OS vulns.. but perhaps someone has an idea?


What aspects of image preparation workflows can lead to accidents like Boris Johnson's No. 10 tweet's 'hidden message'?

Summary:
The most likely explanation is that the old text was removed by using a fuzzy or smooth eraser tool.
Analysis:
In the image below I have only increased brightness and contrast to make the "hidden message" more visible. Nothing fancy. The slight red tint is only due to the fact that the black background of the original has a very slight red tint to it.

As you can see there is a very clear gradient in the most visible hidden text fragment (under "shared priorities"). The other fragments also show some signs of gradients, but there are no gradient effects used in the text about Biden.
Hypothesis:
These seemingly random gradients together with the fact that the "hidden message" appears to consist of small random fragments of a much larger text makes me think that whoever made this picture removed the old text by using a fuzzy eraser tool. They manually swiped the eraser tool back and forth over the text until they didn't see the old text anymore. But the fuzzy eraser tool doesn't remove everything if you pass over quickly just once. This is by design to avoid sharp edges in an image.
In the picture below I have swiped a big fuzzy eraser back and forth a few times over the original image to show what the results may look like. Obviously, in my picture some parts are still a little too visible, but I still think it gives a good idea of what type of effects this could cause.

Solution:
Don't use a fuzzy eraser tool to remove things you want to remove completely. In this case there's no need to use an eraser tool at all. Just fill the whole image with the background color, or maybe even better, just create a new image from scratch. The only thing they wanted to keep was the size and the background color and that should only take a few seconds to replicate in a new image.
Update:
As requested by @Tristan in a comment, I have tried to replicate the process completely. Here is a picture where I have removed the Biden/Kamala text with a fuzzy eraser tool and then placed a new text on top of it:

And here is the same picture but with increased brightness and contrast to highlight remnants of the old text:


There's a number of controls that you could put in place here to give the customer some comfort about the security of their data.  Some of this could well be overkill depending on the customer but ideas nonetheless

Ensure that all the system passwords (e.g. OS accounts, MySQL) are set by the customer for the production system
Assuming that this system will be at a hosting provider as opposed to being on the client site, you could look at setting up Firewall rules at the OS level and .htaccess files at the web server level to restrict where connections can be made from for administrative tools (e.g. SSH, phpmyadmin). This would require the customer to have a fixed IP address that could be used for this purpose.
Documented Change process.  One risk here would be that a code update adds something nasty, so if they want ongoing assurance you'd need to have a defined deployment process where each release is put into production by the customer (assuming that only they have access)
Logging and Monitoring.  At an OS level you could log all activity more info

All this of course depends on the idea that the customer has the knowledge and resources to manage the service.  If they don't and you still have admin access then really it's a trust situation as if you have root access to the box or the database you can take copies of the data.


Physical access to a USB port means you're pretty much screwed.

HID (ie, keyboard) emulation is only one thing that a USB device can do. It can also pretend to be an ethernet interface, or a modem, and offer "network access" to the PC. If the OS helpfully autoconfigures it, and decides to use it, then the device will be able to sniff the network traffic, spoof DNS queries, etc.

More details here.

Now, if you're only interested in stopping this and not the other attacks, you can stop it with software that will detect an excessive typing speed. That won't stop a slow rubber ducky of course. You could check the USB VID/PID of the keyboard, but a USB device can easily spoof these.

Really, USB is physical access, it's insecure.


Generating many keys: how many CSPRNGs to use?

What you want for your key(s) is to be completely unpredictable.

There are now three cases to distinguish which really depend on your "secure random" class / object.

It starts with high entropy and then drops. If your source of entropy is really good, this shouldn't happen, but if it does you may either use a new instance (like you did in B) or you instantiate what cryptographers call a pseudo-random generator (PRG, ie a strong stream cipher encrypting zeroes) using your high-entropy input and use the resulding key stream as continuous source of computationally unpredictable key material. Note that if you use the output directly that the output must be uniformly random which means that if you use a direct physical effect or some gaussian-sampling RNG, you really should securely hash the output of the RNG and then feed it into a PRG which will remove all potential bias.
It starts off badly and then increases in entropy over time. In this case you want to take the entropy you gain over time and condense it into a short-highly unpredictable string using a secure hash function and use that to instantiate a PRG.
It's always a good source of uniformly random numbers. In this case it doesn't really matter which approach you follow, eg using only instance forever, spawning many new instances or using a PRG, all of them should be fine.


question regarding php upload form security

You are correct.  If the ultimate goal is to process the file on the server, then renaming it provides a layer of protection.  However, if you are going to redisplay the file, then renaming it hasn't helped; the attacker just uses whatever redisplay mechanism your site provides.

Let us suppose that your web users can upload pictures that are then displayed on the site.  As the article in your link says, an attacker can upload a picture that contains PHP (or JavaScript, or whatever) in the embedded comments.  If the web server program were somehow (mis)configured to send files with a .jpg extension to the PHP processor, the attacker could run arbitrary PHP code on your machine with the privileges of the web server process.

What this means is that the web developer must carefully sanitize files before allowing them to be redisplayed.  So, you'd:

upload to a random file name and keep track of the name
process the file to sanitize it; how to sanitize depends on file type
rename to an "internal" name; you probably don't want to use the uploader's filename anyway because of name collisions.
Place the sanitized file in a directory in or below the web root, or in a database, and set it up for display.

For image files, you can use ImageMagick to strip comments.  There is a discussion of using the -SET command to strip comments here: http://www.imagemagick.org/discourse-server/viewtopic.php?t=26106  Interestingly, there is also a link to an image, kitten.jpg, that contains embedded PHP.  You might use it to experiment.

Edited 2014-12-02 to add: As Gumbo has pointed out, such an attack can be mounted through a file inclusion vulnerability.  In PHP, all included files start in copy mode, so the PHP processor never sees the binary data of the image, it just scans for the XML processing instruction <?php (or any of the other valid introducers.)  That switches the PHP processor to interpret mode and the embedded PHP code is executed.  When the ?> is encountered, the processor switches back to copy mode and just copies the binary stuff some more.


Is the use of regular OCSP or OCSP stapling a privacy risk?

The usage of OCSP Stapling is actualy the solution to "hide" the visitors from CA's eyes. And of course also for reducing the load on CA's OCSP responders.

OCSP Stapling's principle is that the web server is getting the OCSP response from CA's OCSP responder on behalf of the visitor, so CA can't log the visitor's IP addres, time of the visit or anything else. The webserver then caches the response for some time and serves it to other visitors later (until the response expires). So the CA doesn't even know how many visits or visitors you have.

OCSP responses are signed by the CA so they can't be forged - thus using OCSP stapling is totaly safe.


Is it safe to show user a message if account is locked

While @Simon's answer is excellent, I would like to add one additional point. Do not lock out user accounts due to failed login attempts.

By doing so, you are introducing a huge DoS vulnerability in your application. Any malicious attacker can simply lock out a large number of your users by repeatedly failing the login process. You will also be introducing a large support headache because users will fail the login process. Sometimes repeatedly. Remember the third facet of the CIA triangle, Availability. Your application is useless if no one can use it.

Instead, what you should do is throttle the amount of login attempts allowed. Introduce a "time-out" period instead of permanently locking the user's account pending some action on the users part. This will sufficiently stop online bruteforce attacks while keeping the support emails and calls to a sane level.


Security drawbacks for using short-lived access token in javascript client side

With any API over HTTP you have to worry about Cross-Site Request Forgery attacks.  JSON+REST CSRF is possible.  This isn't taking JSONP or CORS into consideration because the request isn't being performed with an XHR.

Enabling CORS causes huge problems trying to protect your API.  CORS in effect revokes your rights to protect your website with the Same Origin Policy,  it is very similar to having an XSS vulnerability on your website.

A really good method of preventing CSRF is including a random token with each request.  Unfortunately this isn't very RESTful,  but it is secure.  In some cases an attacker maybe able to obtain this CSRF token by abusing JSON(http://jeremiahgrossman.blogspot.com/2007/01/gmail-xsrf-json-call-back-hackery.html), and there are ways of preventing this.  If you are serving this token with a CORS enabled REST api,  then there is no way to prevent an attacker from obtaining this token,  and there for you cannot prevent CSRF.


What is estiamted risk of corrupt public officials accessing survivelance and cloud data in UK?

This questing reminds me of one of my most favourite quotes - Quis custodiet ipsos custodes meaning - "Who will guard the guards?" So basically, what I mean to say is, since you're making the assumption that the police have access to all the business data, there is absolutely nothing stopping RogueTrade Inc from acquiring that data via illegal means. The Govt. is run by people, and that makes it vulnerable.

How probable? Or what is the estimated risk? That's a range - all the way from pretty low to extremely high.

My suggestion - use a cloud service from a place that won't leak your information to your police. For example, Nigeria! I doubt Nigeria has great ties with UK, but I may be mistaken. You see what I mean.

There is nothing stopping you from using a cloud provider from overseas, and international law is really messy. Unless Trade Inc. is an extremely big organised-crime or related company that attracts the interest of the feds and Interpol, you should be fine.

But then again, only use a provider that you trust.

I hope this helps!

EDIT: I would also like to add that there are other ways the data might leak. Ever hear of corporate espionage?


Why clients offer handshaking with SSL 2.0 protocol

A client sends a SSLv2 ClientHello when it is ready to use SSLv2, and it supposes that the server may be an SSLv2-only server. In practice, a given client will always send a SSLv2 ClientHello, or never: the client cannot know what a specific server supports until it has actually talked to it, so it is an all-or-nothing configuration option.

Modern browsers are of the "never" persuasion; some don't support SSLv2 at all (SSLv2 is officially deprecated; its support has been removed from OpenSSL, so Web server using Apache+OpenSSL will soon to support it). But older browser versions could use SSLv2, and some were sending SSLv2 ClientHello by default (I think IE 6.0 did that).

Note that a server can understand the SSLv2 ClientHello format and still not support SSLv2 (i.e. the server accepts the ClientHello only if it internally states that the client also knows SSL 3.0 or TLS).

Since the SSLv2 ClientHello format is incompatible with extensions such as Server Name Indication (there's no room for extensions in that format), and since it makes no sense for a client to send such a ClientHello unless it is ready to actually do a full connection in SSLv2, we can assume that the SSLv2 ClientHello feature will disappear in the future... but we are not there yet.


Are ServerHello, ClientHello, ServerKeyExchange messages encrypted

As stated in RFC 5246:

  The TLS Handshake Protocol involves the following steps:

  Exchange hello messages to agree on algorithms, exchange random
    values, and check for session resumption.
  Exchange the necessary cryptographic parameters to allow the
    client and server to agree on a premaster secret.
  Exchange certificates and cryptographic information to allow the
    client and server to authenticate themselves.
  Generate a master secret from the premaster secret and exchanged
    random values.
  Provide security parameters to the record layer.
  Allow the client and server to verify that their peer has
    calculated the same security parameters and that the handshake
    occurred without tampering by an attacker.

To answer your questions:

a. ServerHello and ClientHello aren't encrypted. (No critical information.)

b. ServerKeyExchange is not encrypted. (No critical information)(To understand how a key exchange without an encryption works, see DHKE)
There is a verification to detected an attacker.


Does MDC integrity protection matter in symmetric encrypt/decrypt of local files?

The original issue was because I was trying to (reasonably) securely feed both the password/phrase and the file to be encrypted into gpg.

I have a simple script that decrypts the file and feeds it (via a pipe) into my editor.  The script asks for the password and it's kept in an environment variable, not perfect but better than putting it in a file or something.

The difficult bit was, after editing the file, to get both the file and the password back into gpg.  It turns out that gpg is actually quite well behaved and where it says " Only the first line will be read from file descriptor n." in the --passphrase-fd description it really means it.  Thus you can simply prepend a line containing the password to the file to be encrypted and pipe both into gpg, as follows:-

<password + file> | gpg --symmetric --passphrase-fd 0 >file.gpg

I can now have:-

s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-count 65011712

in my gpg.conf file such that MDC integrity protection is used (because it comes with AES256) and so I don't get any warnings.

I edit these files on my own home desktop computer so using an environment variable for the passphrase is reasonably OK and I have avoided saving anything in a file anywhere that might persist if something dies on the way.


Disabling SSLv3 breaks TLS 1.1 connections

I've been informed that by disabling SSLv3 it also disables TLS 1.0, and TLS 1.1 because they shared the same ciphers.

This is wrong.
 There is a difference between disabling a TLS protocol version and disabling ciphers. But, a common error is actually that someone tries to disable the use of SSLv3 by disabling all ciphers which were defined for SSLv3 and up instead of just disabling the TLS protocol version. Also, there is actually software out there which does not allow to disable SSL protocol versions but only restrict ciphers.

For example with the mail server Postfix there are various options for allowing or restricting ciphers (smtpd_tls_mandatory_ciphers, smtpd_tls_mandatory_exclude_ciphers) but also options to allow or restrict TLS protocol versions (smtpd_tls_mandatory_protocols). Only the last should be used to restrict the protocol version.


Updating a one time pad using one time pad encryption

Any re-use of the OTP is fatal. What you are proposing is effectively a "two-time pad" which for sure does not have the same security properties.

Attempting to model your cipher in a particular setting:

  Given plaintexts Pi of k bits and an initial key K0 of 2k bits:
  K0 = K0a K0b

  The corresponding ciphertext is the concatenation of the encryption of the Pi and the "update OTP" K1a:
  C0 = C0a C0b
  C0a = K0a ⊕ P0
  C0b = K0b ⊕ K1a

  The key is updated to:
  K1 = K1a K0b

  In the next round we have:
  C1 = C1a C1b
  C1a = K1a ⊕ P1
  C1b = K0b ⊕ K2a

  Note the re-use of K0b. The key is updated to:
  K2 = K2a K0b

  In the next round we have:
  C2 = C2a C2b
  C2a = K2a ⊕ P2
  C2b = K0b ⊕ K3a

  Now we can recover:

  (C0b ⊕ C1b) ⊕ C1a
  = (K0b ⊕ K1a) ⊕ (K0b ⊕ K2a) ⊕ (K1a ⊕ P1)
  = (K1a ⊕ K2a) ⊕ (K1a ⊕ P1)
  = K2a ⊕ P1

Your cipher already fails a chosen-plaintext attack. As you can see above, one can recover the decryption key K2a if you know P1. This allows you to recover P2.

This shows why your cipher is broken.


How private is the data I type in Chrome address bar?

I think you answered your own question:

  But now I've just realized that these bars are not exactly "neutral". For example, the search suggestions feature probably reads the data I typed there and sends it to Google servers, even before I pressed ENTER.

I would not consider your address bar secure or private. Google Chrome will send your address bar searches to your default search engine and you’ll see suggestions as you type. There is another risk when you might actually press enter by accident or that someone else sees your password in plain text. If you type a web address wrong—Chrome will send the address of the page to Google as well (so Google can suggest similar addresses you may have meant to type).

I would suggest you use a other tools such as a clipboard manager to mimic the same trick more securely. Please note I do not know which clipboard managers are actually secure, you would have to research this yourself.

Please note you can disable the prediction service and navigation service mentioned above within your browser, but I don't believe you can fully trust your URL bar to be secure and private.


Importance of Tool-Stealth for Red Team Internal Audit

While it is very useful to be able to grab latest updates etc., you are right that this is not what works in various types of testing. The two most likely are 'stealthy' tests, as you mention, and tests where you do not have a connection outside the network.

The solution is to come with everything you need: all tools and scripts on your testing laptop, or for those tests where you are not allowed to take your own physical kit on site, delivery of your tools to the in-house security team for review and installation onto the test machine.

The list of tools you will want will develop with experience - you'll learn the ones that you typically need for a specific type of test - but I always found that more was better, as if I took a cut down toolset I'd always need one I hadn't brought!

And to be properly quiet on the network you need to configure every tool in stealth mode. Remove 'call-home' functionality. Wind down rate limits where possible. Turn off 'noisy' tests.

If the test allows you to have a smartphone, then using that to check for script updates etc. Is very useful to keep things off the LAN.


What is a similar security standard to ISO 27001 with more focus on IT security?

ISO27k is about the 'management of security', not about security itself. Auditors will be concerned by what you are doing to respond to the risks you have identified, if you are really doing what you're saying, what do you do when something deviates from what has been specified or to new risks, and how do you evaluate the efficiency of your measures.

So basically, they don't care what you are doing to stop ddos attacks (if this is one the risks you're exposed to), as long as you are doing something, and it is deemed efficient enough by a correct indicator.

ISO27k will never say 'this entity is secured', but 'this entity does manage its security well'.

You're not really looking for alternatives to ISO27k, but for something entirely different. There are plenty of standards you can comply to depending on what your business is.


Protecting peers communicating with WebRTC

To state the obvious, you can serve your code over HTTPS.

The architecture diagram shows that it uses SRTP, the secure version of RTP.  It uses AES and HMAC-SHA1.

That leaves the question of key establishment for the SRTP session.  A quick search suggests this has been a sticky issue to standardize.  Clearly this is a goal of the project, but I don't know whether it's been settled yet, and whether there might be tradeoffs that you need to be aware of.  http://www.ietf.org/mail-archive/web/rtcweb/current/msg04050.html

Also see (seems to be focused on issues about UI and granting permission) https://wiki.mozilla.org/Security/Discussions/WebRTC

  Security for WebRTC is (with no surprise) becoming a real rats-nest for some of the use-cases, such as screensharing ala WebEx, remote assistance ala Windows or VNC, ongoing permission ala Skype, etc.

The general impression is that, since WebRTC is an incomplete draft spec, information about its security is incomplete and drafty.


Execute form environmental variable while stack is not executable

That's surely because you are not executing anything in the stack. Without the binary in question, I will try to guess what is happening here.

With the first print "A"*268 + '\x68\x96\x04\x08' you are probably overwriting a pointer to point to 0x08049668. This address is probably a GOT entry for a function called later like printf() or exit().

Then, in the second argument you specify the value that the pointer is pointing to. In other words, you overwrite that GOT entry (0x08049668) with your shell code address (0xbffff891).

So, when the program calls that shared library function (exit(), printf(), whatever(), ...), your shell code will be called instead, because it has been overwritten.

In this process, no code is put in the stack. A pointer in the stack is overwritten. That's all. Then you use that overwritten pointer to overwrite a shared library function address with the shell code address.


Is there an equivalent of Control Flow Guard for Linux?

It appears to that there are two possible implementation working in Linux. One is made by grsecurity named: "Reuse attack Protector (RAP)". Another is in llvm implemented and calls control flow integrity  (cfi). As I understood: CFG is the marketing name of Microsoft for control flow integrity.

The Chrome Team seems to work with that very well.

Most of the information came from Hanno Böck's Presentation. He also provides some more details where CFI/CFG would have helped.
In addition, you might take a look at this. Just not that you get the impression that this is a silver bullet.


Dealing with violating privacy of registered users during failed authentication

I like how the GDPR states: "implement appropriate technical and organisational measures". Now you should take a risk based approach to define appropriate. In sensitive cases like second love this would be totally different then for a more generic service like social media. So no you are not persee exaggerating, but it does depends on the risk context, and or if the data is already available publicly. For example my github account shows my email in the commits.

The Privacy by Design principle Full Functionality – Positive-Sum, not Zero-Sum states:

  Privacy is often positioned in a zero-sum manner as having to compete
  with other legitimate interests, design objectives, and technical
  capabilities, in a given domain. Privacy by Design rejects taking such
  an approach – it embraces legitimate non-privacy objectives and
  accommodates them, in an innovative positive-sum manner.

So, I like how you are trying to find a way to be both user-friendly, secure, but also respect privacy. Sounds like you might find a new innovative way, be sure to share your findings.

To be on the safe-side you could always send out the same reply that does not expose anything. You could do usability testing to see if this really an issue. Personally I think if I cannot login and immediately a reset password link is shown, that that is more user-friendly. Since this often the next step I take. If the reply is the reset password link has been sent, but if the account does not exist you send a registration email instead, that would also feel user-friendly. As I can now just signup instead. Without exposing if I already have an account to the public.

Similar you could always handle the registration process by email, this way you know the owner is the only one to know his account already existed. An email like: Hi, your email address already has an account, do you want to reset your password instead?

Now if all fails, you could ask existing users to give consent to expose that they are using the system, for the purpose to make it more user friendly. Pretty sure this is not a good idea though...


First, let me say I agree with your assessment that the SAQ A-EP is what you should be using (assuming your volume qualifies you for Level 3 or 4, less than 1 million annual transactions). This is a huge change to PCI and I imagine it is going to cause some serious ripples in the payments space.

My understanding of the phrase "shared hosting" in terms of PCI does not apply to Digital Ocean or any VPS provider. However, they are still a hosting provider and as such have access to the cardholder data. They do say on their Security page that engineering team employees have access to the backend host servers. It is therefore entirely possible for them to access your Droplet if they wanted.

The way you can think of this is, if they hired a malicious person, could that person access and modify data on your Droplet. If they could modify something on your Droplet, they could add JavaScript to the page to siphon off cardholder data before it is sent to Stripe. Now, I think we would all expect that Digital Ocean has controls in place to monitor/audit these types of things and that is where PCI comes in. They should undergo a PCI Level 1 Service Provider assessment to validate their controls. It looks like this has come up before and they said they were not pursing any sort of PCI compliance at the time.


Is it good idea to use a access point MAC address as wifi password?

The answer is: No it's not a good idea.

There are several reasons for that. The first and most important is that the mac address of the router is broadcastet by the router multipile times every second. This is done by sending so called "beacon packets" which contain a log of information which is realted to that access point. This means the mac address can be obrained by simply running a tool like airodump-ng which captures and displays the content of these packets.

Also it is never a good Idea to use a password that has a direkt relation to the service it is used for or the person the account is associated with. This is because its very common for attackers to create wordlists from every pulic available source that is related to the target. This might also contain a scan of the wireless networks and in that result the mac address of the accesspoint.


Generating shared secret key using existing receivers public key and senders private key

You don't need to do this; this is already solved by the SSL/TLS handshake.

The SSL/TLS handshake goes a bit further, in that it not only establishes a secret by using both the public and private keys of both parties, but also uses a certificate to establish that the server is who it reports to be - preventing a man-in-the-middle attack.

A quick, more detailed description of the steps involved is here.

But since you tagged the question with "HTTP", I assume you want to send the file via HTTP. Just using HTTPS means you're already using SSL or TLS for key exchange, negotiation of a secret key, and usage of that secret key for encrypting the file while it is in transit. And some protection against MITM in the process.


Why am I receiving hits with SPT=443 on IPv6?

It seems your server is connecting to that IPv6 address, which is assigned to Google, on HTTPS and this is the reply from that server, as you can see by the SYN and ACK flag.

My guess would be that your firewall is not allowing established connections initiated from the 'inside' and thus is blocking this traffic.


Adding one's own cryptography implementation on Android

Generally you would not want to add your own cryptographic implementation of any secure protocols or algorithms.  There are a few reasons for this:

It is unlikely that you will code a correct implementation on the first go.
Your code has not be scrutinized for years like many open source cryptography libraries.
Your code will most likely be slower regardless of which JCE or OpenSSL engine because other libraries have already been optimized for speed.

Android provides an API for interacting with the OpenSSL library that is already present.  This is called Spongy Castle, which is a modified version of Bouncy Castle.  The algorithms it supports should already meet your needs.  Here is some example code using the API.

That being said, and I encourage you not to use your own implementation, there are two routes you can go.

Custom JCE
This is probably more up your alley and what you want to do.  Here is a link to How to Implement a Provider.  Here you provide classes for each cryptographic service you want to implement.  You will most likely need to sign your provider, and provide your application with the public key to verify it.

Adding a Shared Library
A more fun way (in my opinion anyway) is to create your own crypto-implementation by adding a shared crypto-library to Android, and provide a JNI for your application to use it.  The main library would be written in C, and cross-compiled for ARM using Android's NDK.  You'll then need to write a Java Provider (JNI) that can be registered with Dalvik in order for your application to run it.  Here is an example of installing a different crypto library to your phone.

This has the disadvantage of needing to rebuilt Android and flashing your device.  Not ideal for an application installing from Google Play.


Nmap scan comparison show change in ports

1) Nmap Timeout

I do not know how Nmap determines that but I'm fairly sure that it takes respond time into account while deciding if the target port is open or not. Depending on various factors, a port may not be able to respond immediately so maybe Nmap decides that the port is closed. Lets say that the threshold is 100ms. At first Nmap gets a response in 89ms and at second try it gets a response in 105ms. In both situations the target port is actually open but fails to respond in time.

2) Firewall Rules

The target machine does not need to have a full blown IDS in front of it, port scan is a really simple threat to detect. Limiting packet number over time from a single IP can disable your scans for a while. The funny thing is, since Nmap governs asynchronous scans it may scramble the order. That means Nmap might exceed the threshold while scanning port 8080 on one thread, and it might not have been scanned the port 50 yet. It could give you weird results.

My Recommendations

Use the "-T" flag of the Nmap. For example, use -T3 instead of -T5 so the scan will be slower but more docile.
There are flags for timeouts such as "--max-rtt-timeout" and "--max-scan-delay", take advantage of them for slower hosts.
Implement a better change detection algorithm. Instead of just checking the current result with a previous one, compare how many "CLOSED" or "OPEN" results you've got in a certain time. There are many false positive and false negative detection algorithms you can find on the internet. (SANS explains False Negatives security wise, here)


Those are DNSSEC NSEC3 hashes.

The possible duplicate that @S.L.Barth suggested includes an answer which references a tool called hashID.  Running that tool on your hashes indicates it's DNSSEC NSEC3:

$ hashid 399wm0836ohh4w1rhhu880ery7533qt9
Analyzing '399wm0836ohh4w1rhhu880ery7533qt9'
[+] DNSSEC(NSEC3)
$ hashid 054wi5753pdq8j4ikuc800fbd9917te3
Analyzing '054wi5753pdq8j4ikuc800fbd9917te3'
[+] DNSSEC(NSEC3)
$ hashid 783bg3857sdv6o7rbgv383ydg5159mr7
Analyzing '783bg3857sdv6o7rbgv383ydg5159mr7'
[+] DNSSEC(NSEC3)
$

DNSSEC NSEC3 records are documented in RFC 5155.  Appendix A of RFC 5155 includes examples that are homomorphic to yours:

   ; H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
   ; H(a.example)     = 35mthgpgcu1qg68fab165klnsnk3dpvl
   ; H(ai.example)    = gjeqe526plbf1g8mklp59enfd789njgi
   ; H(ns1.example)   = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
   ; H(ns2.example)   = q04jkcevqvmu85r014c7dkba38o0ji5r


For private key storage, you will find mostly:

What OpenSSL does. This actually is the ASN.1 format specified at the end of PKCS#1 (type RSAPrivateKey). When that object is Base64-encoded into PEM format, the header will be: -----BEGIN RSA PRIVATE KEY-----. The raw (binary) format is "as is", but PEM includes options for symmetric encryption (with a key or a password). This PEM format is not really standardized or documented; it is "what OpenSSL does".
PKCS#8. For a RSA key, it will be a wrapper around the ASN.1 format from PKCS#1, with an explicit specification of the key type (i.e. "this is RSA"). PKCS#8 also includes options for symmetric encryption. OpenSSL also supports PKCS#8 and can encode it into PEM, this time with the header: -----BEGIN PRIVATE KEY----- (notice the difference with the previous case: the key type is no longer specified in the PEM header, since the ASN.1 structure contains that information). While a PKCS#8 file which is PEM-encoded could contain PEM-level encryption, this is rarely done since PKCS#8 can also do it internally. PKCS#8 benefits from support in many frameworks, e.g. Java knows that format natively.
PKCS#12, also known as "PFX". This is in fact a generic archive format which features optional encryption and integrity checks, and can be used to put together one (or several) private keys and the corresponding X.509 certificates. If you store public keys in certificates, then you will want to use that format since it is natively known by many systems (Windows and MacOS X can read it directly, for instance).
The OpenPGP format. This is what will be used in most "keyrings" as handled by GnuPG. It is not based on ASN.1. If you have to reimplement it yourself, then it is somewhat simpler to manage than PKCS#8. This format is rarely known natively by existing programming frameworks, but ready-to-use opensource libraries are available (e.g. GnuPG or Bouncy Castle).
What OpenSSH supports. SSH has long used its own formats, but for private keys, OpenSSH can feed on the OpenSSL formats (both the OpenSSL-specific and PKCS#8).

For public keys, there are a few twists:

In the OpenSSL and X.509 worlds, public keys don't exist "as themselves" but only as part of X.509 certificates. You may want to store your public key in a certificate structure, which could be (by tradition) self-signed, since there is a "signature" field in the X.509 certificate format. The part of a certificate which contains the public key itself is called SubjectPublicKeyInfo (look for it in the standard) and is a wrapper around an algorithm-specific format, which brings us back to PKCS#1. DER-encoded SubjectPublicKeyInfo structures are occasionally spotted in real-world applications, but they are quite rare.
OpenPGP has its own formats for public keys.
OpenSSH has its own formats for public keys. Mind the plural: there are several. Start here for descriptions.

For interoperability and integration, I'd say that it is a tie between X.509+PKCS#8 (with possible use of PKCS#12), and OpenPGP. Personally, I'd use the former, but that's mostly out of habit.


Why does generating a self-signed X509 certificate not require my public key?

The private key is the secret that identifies you, any signing or verification of your specific identity need the private key. So any operations that will generate something meant to be derived from your identity will require it.

Also, you are not creating a certificate here, you are creating a certificate signing request, something you would hand to another party to whom would then generate the certificate to grant you access.

if you want to create a self signed x509 certificate you should add the -x509 parameter, something like this:

openssl req -x509 -nodes -days 5000 -newkey rsa:2048 -keyout mypem.key -out mycert.crt

where days are how long the cert is valid (5000 is effectively
indefinite)
nodes skips password business (skip for testing, omit for anything real)
and also output the key and cert for later use

And @bartonjs is correct, private key to public key is possible, public key to private key is not. That's why you can hand out the public key and noone can use that to impersonate you. The private key must be secret at all times.

If you are planning to act as the client wishing to gain access to the server and also the server granting the request you will first need to set up your certificate authority on the server, and the server's certificates.

Somone on stack overflow has a great answer on this already:

https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority

But the basic juiste is, you set up the CA and crt of the server then you do something like this on the server:

openssl x509 -req -days 30 -in request.csr -CA ca.crt -CAcreateserial -CAkey ca.key -out signedrequest.crt

you hand the "signedrequest.crt" back to the person who requested it.

I forgot to mention, get rid of -nodes in my command above, it skips the password process. Good for testing, Bad for security. Just FYI.


How to report a security vulnerability involving multiple unrelated companies?

Involve a trusted third n-th party.

While JonRB's approach can work, involving another trusted party, like a national or transnational CERT, can speed up the process and bring it to the desired outcome.

We have seen in the past, that big companies did not react properly to reports of major bugs/vulnerabilities in their products. The companies in question either did not react at all, did not try to develop a solution or sometimes the issue just got lost in a big corporate labyrinth. This ultimately led researchers to publishing vulnerabilities on their own to pressure vendors.

When you involve another trusted like a CERT, you can be relatively sure that the affected companies will realize the seriousness of the matter and handle the issue with a certain elevated attention.

Be sure though, that you trust the party that you plan to involve. If the companies that are involved are based in different countries there is probably no one single entity with authority over all of them. Luckily most of the world's bigger CERTs work together and are (somewhat) organized.


Alternative approaches to using DMZ for securing communication to and from external web server outside firewall

The traditional answer is a three-tier architecture: web, app, and data.  Your web layer is isolated out front, and can only talk to the app server with limited methods (e.g., only a small number of RPC-ish calls available).  The app server then talks to the data(base) layer, and of course you can do whatever with ACLs or stored procedures to make that more secure.  For security purposes, a three-tier architecture is a good solution when done right.

You're peer's suggestion about only allowing port 80 is sort of an assumed minimum.  And whitelisting the verbs is fine, but realize that the majority of attacks you'll face operate above that layer and will route quite happily over GET/POST.  Which leads into the modern answer: Intrusion Prevention Systems that'll watch all the traffic going by, detect malicious patterns, and act to interdict them.

The traditional answer and the modern answer all lead up to the real answer: you can't set [an external web server] up that's as safe, reliable, and secure as not having one in the first place.  Whatever you do will increase your risk by some margin.  How you do it will change how big that margin of risk is.  Whether you go with a three-tier architecture, IDS/IPS, log monitoring and alerting, etc...  You and your management decide how to mitigate the risk, and get it to an acceptable level.

And unfortunately, learning how to safely mitigate the risk means digging through 500 page PDFs to learn the tricks.  A hat for a cat, or a cat for a hat, but nothing for nothing.


This is great that you are doing so much learning on your own.  You are on the right track.  Your enthusiasm to learn on your own will put you a step above a lot of your competition.  Kudos.

My main advice would be: don't worry too much about planning out a path through all the material you want to learn.  You don't need a carefully thought-out plan.  Instead, get your hands dirty, play around, don't be afraid to explore.  When you see something that looks cool, follow up on it opportunistically.  At first you might be overwhelmed but in the longer run I think you'll find it a valuable experience.

I think one good experience is to engage in a security evaluation of a software system.  This would be a fun experience for you.  You could pick an open-source web application or web programming framework and do a security evaluation of it: do an architectural risk assessment (what Microsoft calls "threat modeling", with STRIDE and the like), read the code and do security code review, try out some static analysis tools.  Then, write up your results and post a blog entry with your evaluation.  Do this a few times and I think the experience will be extremely helpful for you.

Another very good experience for you would be to build a non-trivial web application or two.  I like web2py as a web programming framework for its ease of learning curve, but alternatively picking something that's more popular (e.g., Ruby on Rails, PHP or one of its frameworks) might be good experience to see what the issues are with common frameworks.  Write a web application, with some client-side JavaScript code.  Play around learning how to use jQuery or the like.  Maybe experiment with Node.js.  I think this will be a fantastic way to get exposure to some of the challenges and mindset that web developers are likely to face.

Depending upon your personality, you might find it fun to create a blog and write down fun things you have learned, as you learn them.  For many people, the act of writing something out solidifies it in your brain and forces you to understand it better.

You mentioned practicing hacking a web application.  Learning how to hack a  web application is fun, and it is worthwhile up to a certain point.  It's good to have some hands-on experience hacking a web application, to help you think about the risks and to make the concepts concrete.  However, I wouldn't make it the primary focus of your learning.  Web penetration testing is a lower-end activity these days, with less promising career opportunities, so I wouldn't advise trying to focus your energy on learning to be a web pentester.  That's not how I'd advise you to position yourself, if you have the choice (and it sounds like you do).


It might, who knows?

You are installing a software on your computer. Except if you had the source of that software (that you audit, that is self-contained, etc.) and you compiled it yourself and you did the compilation on a trusted host with a trusted compiler (see the famous Thompson article on trust), you otherwise can not have any guarantee on what it is doing or not. If it is installed under an Administrator account/service (probably needed for a VPN), expect that it can do everything.

Even if you are installing things on your own computer and not one of your employer, you may still be mandated by some policies tied to your contract on what you can or can not do with your equipment using some of your employer resources (network, etc.).

If you would like to have some safeguards, you should use VMs or equivalent so that you can segregate your work from your non-work use cases on your own computer. Or equivalent technologies (ex: on Linux you have network and filesystem namespaces so you can restrict what a process sees on the system regarding files and network capabilities).