using truecrypt keyfiles with weak passwords

If you think the keyfiles are secure, then no password is needed, if you can not have the risk of the keyfiles leaking, then you need to password protect them with a strong password. No password or a weak password is practically the same.

You can store your keyfiles within another truecrypt volume with a strong password, this way you only need to remember one password and your keyfiles are secure.


Is there any reason to log out of websites?

HTTP is a stateless protocol. Being logged into a website means that a shared state need to be kept between client and server. This is usually accomplished using a shared session ID which is commonly stored on the clients side as a cookie and on the server side in a database. If the attacker can make use of this session ID he can do actions as the authorized user.

Cross Site Request Forgery (CSRF) is a common attack to misuse this cookie even though the attacker cannot read the cookie's value. This attack is for example used to hijack and reconfigure routers so that they can be used to man in the middle any connections to the internet.

Other attacks steal the session ID for example using Cross Site Scripting (XSS). Of course the session ID can also be stolen by hacking the server or its database for example using SQL injection or simply be guessing the correct session ID in case of easily predictable session ID's.

While all these attacks can be done when the user is logged in a properly implemented logout invalidates the session ID which then can no longer be misused. This way the attack surface is reduced.


What information can Adobe Reader and MS Word send over the internet when a document is opened?

When started, Adobe Acrobat can initiate a "phone home" to check for an update; this might include an installation-specific ID that could be exploited by an intelligence agency, so your TOR session's address might be associated with your installation. Or the document may have a custom unique certificate with a CRL that identifies the reader when it's checked, or that certificate ID could be monitored at an OCSP server. Or there may be malicious code exploiting an unpatched bug in Word that communicates back to whoever is trying to trace the document.

DOC and PDF documents are likely being called out because they have historically had poor track records with respect to exploitable bugs.

It's possible to configure Acrobat Reader to not intentionally communicate, and to turn off macros and such in Word, but one careless setting and you may be completely exposing yourself. Not opening the documents while online simply avoids most of the potential vulnerabilities, and is very easy advice for people to follow.


What information does a wireless access point have about connected devices?

There is a lot more of information the access point has about any connected device. At least:

the protocol used
some kind of signal strengh
the current key for encryption
some history for packet delivery
the data sent and received as the first hop of the device to the network
time of the connection

Depending on the time constraints and the bookkeeping, also enough data to roughly guess the position of the device.

There might be even more data available; I would have to take a look at the protocol definitions to see what else is shared.


If I port scan a server on the outside of a firewall will this also tell me the ports the firewall is blocking?

You have to make sure that the external server answers on every port, which is quite unusual. But if that is the case you are on the right track.


What are best methods to mitigate damage from MS Office VBA macro viruses?

See this recent article. Basically you need to configure a trusted location within Administrative Templates.

Obviously this is for Windows only. Not sure if it is possible for OSX.


How can a DoS attack be used as part of the 'Gaining Access' phase of a hack?

DoS attacks can be used in several ways as part of gaining access:

Overwhelming primary defenses. when you are conducting a DoS attack, the primary defense mechanisms get caught up in it too. They can be overwhelmed and as a result, they may: a) not respond appropriate b) can hang altogether c) the watchers watching them are distracted, or your efforts are lost in the DoS logs. In addition, if the primary systems are rolled over to secondary systems (which often happens) those may not be up-to-date configurations, or you could catch the roll-over in a time-gap whereby the synchronization of everything is not current.
Overwhelming primary systems may expose flaws. A DoS attack may be used to expose flaws that could be exploited. Could be procedural flaws, it could be system flaws. It could be that as a result of a DoS attack you force the organization to upgrade, and during the upgrade you take that window of opportunity to exploit.
The DoS attack is a decoy. Classic attack... What magicians do all the time. Watch the left hand while I steal with my right. The DoS has so much focus of the organization, secondary routes into the system (physical, social, or technical) could be undermanned, provisioned or systems can be more easily by-passed without being noticed.
DoS attack could be a plant. I once heard of hacker who conducted a limited DoS attack on organization A, because he had done his research, and the CIO from organization A was very close to organization B, and both organizations were in the same general business arena. So he suspected that if he could get organization A to adopt a specific technology to thwart his rather crude DoS attack, that organization B would do the same - thinking they might be next. He was very correct, as organization B did. Why? Well the hacker had an 0day exploit in the piece of technology and he wanted to attack organization B.
Secondary Route/Bridging Exploitation. An extended DoS attack that can be sustained, can force business units within the organization to move to secondary systems paths (networks) to keep critical business going. While some of these secondary paths may be well-planned and secured, many are not. For instance a business unit may stand up a wifi, or mifi device and start using it as their business network without any security infrastructure. If an attacker is actively monitoring and profiling, they may be able to capture and attack these very vulnerable paths and now you have a direct, totally unsecured bridged network into the organizations intranet.


Why is client-side hashing of a password so uncommon?

Inventor of JavaScript password hashing here

Way back in 1998 I was building a Wiki, the first web site I'd built with a login system. There was no way I could afford hosting with SSL, but I was concerned about plaintext passwords going over the Internet. I'd read about CHAP (challenge hash authentication protocol) and realised I could implement it in JavaScript. I ended up publishing JavaScript MD5 as a standalone project and it has become the most popular open source I've developed. The wiki never got beyond alpha.

Compared to SSL it has a number of weaknesses:

Only protects against passive eavesdropping. An active MITM can tamper with the JavaScript and disable hashing.
Server-side hashes become password equivalents. At least in the common implementation; there are variations that avoid this.
Captured hashes can be brute forced. It is theoretically possible to avoid this using JavaScript RSA.

I've always stated these limitations up front. I used to periodically get flamed for them. But I maintain the original principle to this day: If you've not got SSL for whatever reason, this is better than plaintext passwords. In the early 2000s a number of large providers (most notably Yahoo!) used this for logins. They believed that SSL even just for logins would have too much overhead. I think they switched to SSL just for logins in 2006, and around 2011 when Firesheep was released, most providers switched to full SSL.

So the short answer is: Client-side hashing is rare because people use SSL instead.

There are still some potential benefits of client-side hashing:

Some software doesn't know if it will be deployed with SSL or not, so it makes some sense to include hashing. vBulletin was a common example of this.
Server relief - with computationally expensive hashes, it makes sense for the client to do some of the work. See this question.
Malicious admins or compromised server - client-side hashing can prevent them from seeing plaintext passwords. This is usually dismissed because they could modify the JavaScript and disable hashing. But in fairness, that action increases their chances of being detected, so there is some merit to this.

Ultimately though these benefits are minor, and add a lot of complexity - there's a real risk that you'll introduce a more serious vulnerability in your attempt to improve security. And for people who want more security than password, multi-factor authentication is a better solution.

So the second short answer is: because multi-factor authentication provides more security than client-side password hashing.


What happens when encrypted email is in-transit?

It depends on the design of a particular service, but if you send an email outside of a service providing encrypted emails it is subject to the same relaying mechanisms as every other email on the Internet.
This means you don't know and have no control over (and that's reason you want to avoid sending unencrypted emails in the first place).
Regarding ProtonMail it offers two solutions for encrypted communication with recipients outside the service (source Wikipedia, March 2016):

Emails sent from ProtonMail to non-ProtonMail email addresses may be sent with or without encryption. With encryption, the email is encrypted with AES under a user-supplied password and then stored on ProtonMail's servers. The recipient receives a link to the ProtonMail website on which they can enter the password and read the decrypted email.
(...) ProtonMail added native support to their web interface and mobile app for Pretty Good Privacy (PGP). This allows a user to export their ProtonMail PGP-encoded public key to others outside of ProtonMail, enabling them to use the key for email encryption.

In practice a test email (with both encrypted and unencrypted content) from @protonmail.com to @gmail.com email was sent directly between the two parties using encrypted and authenticated protocol ESMTP with STARTTLS:
Received: from mail2.protonmail.ch (mail2.protonmail.ch. [185.70.40.22])
        by mx.google.com with ESMTPS id e3si15787607wjn.27.2016.03.18.05.07.18
        for <________@gmail.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 18 Mar 2016 05:07:18 -0700 (PDT)

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of _________@protonmail.com designates 185.70.40.22 as permitted sender) smtp.mailfrom=________@protonmail.com;
       dkim=pass header.i=@protonmail.com;
       dmarc=pass (p=QUARANTINE dis=NONE) header.from=protonmail.com

This post also touches on the subject of encrypted email transmission.


Is Opal-based full disk encryption fully working for Linux?

First, if your BIOS can handle an Opal SED, then, yes it will work for Linux. Check your BIOS to see if it supports Opal.

Second, SED's protect against someone stealing your computer when it is powered off. In a sleep state, the SED is still drawing power and therefore exposed. So if an attacker steals your computer and wakes it from the sleep state, they potentially have access to all your data.

Third, tools like sedutil make SED's independent of the BIOS. They are no more intrusive than BIOS solutions in that they ask for a password at boot time and then get get out of the way. The only drawback is that they take more effort to install than a pure BIOS solution.

At this time, sedutil will work with any BIOS that does not cut power to the SED during a reboot.


Best way to triage crashes found via fuzzing, on Linux?

Here's the best heuristic I know of.  Run the program under Valgrind memcheck, and then look at the warnings that Valgrind outputs.  We can classify them into a couple of categories:

Invalid write: Look at the address.  If the address is small (say, between 0x0 to 0xFFF), then this is a NULL pointer dereference: probably not exploitable, low priority.  Otherwise, this is a write out-of-bounds: potentially exploitable, a serious high-priority bug.
Invalid read: Look at the address.  If the address is small (say, between 0x0 to 0xFFF, say), then this is a NULL pointer dereference: probably not exploitable, low priority.  Otherwise, this is a read out-of-bounds: could be exploitable if you're unlucky, but often these bugs are not exploitable; call it medium-priority.
Invalid free(): This could be a double-free bug, and there's a significant chance it could be exploitable.  High priority.
Mismatched free() / delete / delete[]: Potentially exploitable, depending upon the circumstances.  Medium priority.
Conditional jump or move depends on uninitialised value(s): While such bugs can sometimes be exploited, exploitation is by no means guaranteed, and it is not likely to be easy.  Often, these are benign false positives.  Medium to low priority.
Syscall param ... points to uninitialised byte(s) or Syscall param ... contains uninitialised byte(s): Same as above.  Medium to low priority.
Source and destination overlap in ...: Very unlikely to be exploitable.  Low priority.
Memory leaks: (e.g., Still reachable, Definitely Lost, Indirectly Lost, Possibly Lost): Very unlikely to be exploitable.  Low priority.

This is the best heuristic that I know of.  I don't know of any tool that implements it for you, but it's not too hard to script up yourself.  Does anyone know of a better triaging heuristic or tool for Linux/Unix systems?


How do i protect my self from "Form grabbing" attack?

Form grabbing attacks happens when a malicious script/program captures your form with your private information.  The most straightforward way to do this is with javascript extension.

The best prevention is to:

use your own trusted computer (malware that could capture form data),
install your OS/programs from trusted source,
do not install browser extensions/user scripts (especially from untrusted sources) or at the very least use private browsing (with all extensions disabled) when you go to these sites,
use a modern up-to-date browser,
only use passwords over https connections (this makes it more difficult for attackers to insert javascript in cross-site scripting),
Also consider disabling javascript.

EDIT:

My original answer mostly was concerned with your title How do i protect myself from "Form grabbing" attack? versus instructing you on how to write security software.  Otherwise I agree with CodesInChaos remark: "It's an unwinnable battle".

There are two distinct places form-grabbing could occur: either from the browser (e.g., an XSS attack loading malicious JS, or a malicious extension installed in the browser) OR monitoring API calls via hooking.

There are a variety of ways of hooking, but if a user/malware has sufficient privileges to insert API hooks, they probably also have enough power to make the output of your hooking detection tests untrustable.

For example, if someone was mounting this style of attack to log all http/https requests you could detect try to detect if the shared library (aka DLL) has changed (granted every benign upgrade to that library will trigger false positives) or contains a certain malware signature.

Now let's say the altered shared library is saved to disk in its altered form.  Now your anti-hooking program computes a cryptographic hashsum to check that the library has not been altered to compare against the known function of the unmodified library.  But what prevents the attacker from just hooking into those calls to calculate the checksum and altering the output to be the pre-modified checksum whenever the malicious checksum comes up?  Nothing, unless of course you are analyzing a hard disk from a safe operating system (e.g., mounted the drive read-only from another computer not infected with the malware).

Granted, due to threats of runtime modification of libraries, you really need to check the instructions in the memory of the process that is running versus the static files.  In this sort of situation, you really need to have the potential malware running to capture the API-hooking attack, though all your safe utilities cannot be trusted as the system has already been compromised.  (You could still scan the disk from a safe setup for whatever program is eventually altering the memory to insert the API-hooks, but its a much harder task where you only find the types of attacks you know to look for).


How are DNS requests sent when using OpenVPN? Are they encrypted?

In a default configuration, all traffic (including DNS) should be routed through an OpenVPN tunnel.

However OpenVPN in itself does not provide mechanisms to enforce all traffic being routed via its tunnel and if an application or the operating system decides to route traffic via unencrypted interface, it is free to do so (as was the case with Windows 10 Smart Multi-Homed Name Resolution).

As for your intention—protection against snooping on DNS queries by ISPs—you would be better off by configuring and using dnsmasq with DNScrypt even for your non-VPN connections.

By adding an outbound firewall (e.g. iptables in Linux) rules to block all DNS traffic you could ensure that even in case of OpenVPN failure or misconfiguration, you would get a fallback to an encrypted DNS channel (or no connection at all because of FW).


What you encounter is NOT an iSCSI hack, but malicious bitcoin miner that place in your system that mask as a iSCSI process (which is not).

Kill the process /var/tmp/iscsid_pirate  process, check your crontab.  If you don't believe it is malicious, you can run

sha256sum  /var/tmp/iscsid_pirate

copy the hash and paste into https://www.virustotal.com/search bar. Due to bitcoin miner abuse, most antivirus flag bitcoin miner as something bad. Don't be surprised that mainstream Windows antivirus flag them even it is a Linux ELF file.

What you should do :

Check your web services for security flaw.(e.g. outdated version, unpatched security updates,etc)
Backup your data
Reinstall and redeploy the server, patch all the security holes before open up to user. (You need no.1 to backup your claims that you have been hacked instead of a rouge admin put the bitcoin miner in your system).


Modsecurity Encrypted traffic in 3 tier architecture

That depends entirely on your configuration and your wishes.

Your setup certainly could re-encrypt  after analyzing with mod_security and before forwarding to your application server. You would do so by using the ProxyPassReverse and SSLProxyEngine configuration options - see this question for an example.

So that begs the question: should you use TLS between your webserver and your application server?

To answer this question you'll need to assess your network and determine if you actually trust it sufficiently to retransmit your requests in the clear.


I've seen this done on old Compaq servers. The side panel had a pin that fit inside the power switch. When the panel was opened, the pin came with it, shutting off power. In fact, the system would not even power on without that side panel (more specifically, the pin) in place.

It was quite a surprise when I was called in to service a server off-hours and I was unfamiliar with this mechanism. I was hoping to diagnose a problem without any server downtime, but I was foiled.

Short description:
PC Mag article


Does HTTPS protocol leak HTTP body length?

Distinguishing header from content is usually not the hardest part of cryptanalysis. This is because headers usually come with a specific structure, common length range and limited value variety.

Yes, SSL/TLS is leaking length details which might be used for multiple classes of attacks. In some cases an attacker might be even able to determine content information. Check the Bicycle Attack for some details: https://www.scip.ch/en/?labs.20160317

Padding is a good idea to prevent such attacks. There is no notable downside by definition regarding security adding such a feature.


How do I immediately block IPs once they do a single malicious act?

You are asking the wrong question, for a number of reasons.  These are mainly spelled out in comments, but I think it's worthwhile to put it all in a coherent answer.  There are a number of critical issues that you'll run into if you attempted to do this:
1. Identifying malicious acts is the hard part
Blocking an IP that you suspect is performing malicious activities is easy.  This is what a firewall is for after all.  The tricky part is correctly identifying malicious activity.  As was pointed out, at least some of your "malicious requests" were almost certainly search engines doing standard indexing.  You don't want to block them.  Moreover, requests that are actually malicious are often very difficult to identify.  It can be easy to look at it after the fact and decide, "Yup, this is definitely an XSS vector - ban it", but some well crafted payloads may be difficult even for trained security professionals to identify.  Teaching a computer to do it automatically is effectively impossible.  In fact, if you did manage to do that, you would have a security product that you could sell for ridiculous amounts of money.
2. Banning it after-the-fact is too late
If you ban an IP address after it makes a malicious request then your ban has come too late.  In many cases, a single request may be all that is necessary to do substantial damage.  If you ban an IP address after little bobby tables registered, then your system will already be broken.
3. Banning IP addresses bans the wrong thing
It's easy to think that "Banning IP address" === "Banning attacker", but reality is far more complicated with IPV4 and NATs.  Home networks, companies, large government organizations, and sometimes even geographic regions may share a single IP address.  Even if banning an IP address actually banned an attacker, you will never know how many other legitimate users you accidentally banned as collateral damage.  You don't want to ban the IP address - you just want to ban the request.
Solutions
A ban hammer is really the wrong tool - more finesse is required.  The most common solution is a WAF although even those are far from perfect.  The reality is that there is no easy way to security, and properly securing an application requires effort at all layers of it.  Tools like fail2ban perform tasks similar to what you are seeking, but are working at very specific levels of the application.  A broad "malicious activity" detector of the sort you are looking for is much, much, harder.


Accepting other similar passwords when storing a salted, hashed password

If someone were to get a hold of this database and try cracking the
  passwords, would allowing these additional combinations significantly
  reduce password strength?

I would argue that it would not in this specific situation.  I highly doubt that they are storing three forms of the hashed password in the database, but rather hashing three different versions of the provided password and comparing it to the one hashed password that is in the database.

There is an interesting post on here that discusses how Facebook has this password functionality. and while it doesn't go into exactly what is going on in the background, the consensus seems to be that it is not a significant security risk.


Reasons not to preserve the certification path on an intercepting HTTPS proxy

What might be the main reason we don't see this?

There is not much added value with this in my opinion. As you already noticed these information would be fake anyway. Actually, I find it useful that if somebody has a look at the certificate (most don't care anyway) it would be obvious that this is not the original CA but a local one explicitly provided for SSL inspection.

  Would there be a better alternative, if we would like to preserve this information for the client?

While most end users don't care as long as the browser does not complain, for some it would be useful to get the original certificate and chain, i.e. not a similar one but the real one. This could for example be done by providing a specific URL where the intercepting proxy simply delivers information about the original certificate as was seen by the proxy, i.e. something like https://proxy/give-me-the-original-cert?domain=.... I know of at least one product which has implemented this approach at the request of a customer.


Can a second router be used as an artificial firewall?

Assuming the routers you are using have stateful access lists then they can be used as basic network firewalls and the design you have will provide some very basic defense in-depth benefits. If it's a possibility you may want to block all inbound packets initiated by the Free-BSD server entering the second router (clients behind the second router can still access the server but not vice-versa because TCP ACK 0 packets inbound to the internal network will be blocked).

Will it work ? yes but it might be easier if you segment the network ranges so they don't overlap. Maybe use a 192.168.1.x network and a 192.168.2.x network (there's a LOT of ways to do this, I'm just throwing out a really basic example)...

Has this been done before ? Yes, a long time ago before firewalls were popular and inexpensive this is one way people segmented networks.

Note: Just because this works doesn't mean it's a good idea. Some routers temporarily drop their filtering rules when under duress and allow "all" traffic through. Firewalls don't generally behave this way. Likewise almost any firewall will offer a lot of additional features that the routers won't be able to offer you.

If you are on a budget I would highly recommend simply using something like IPTables or PFSense.

As a side note if your First router has 3 interfaces you can also use one interface to connect to the Internet, a second for your Free-BSD server and then use the third for your internal network and not need the second router to create the same type of segmentation. (think Y-shaped network diagram)


There is tons already written on this site about salting.  Please go read that, and then come back if you have further questions.  Don't miss Password Hashing add salt + pepper or is salt enough?.

TL;DR: Each user should receive their own individual random salt, stored in the database, next to the hash.  You could optionally also include a second application-wide salt ("pepper") stored elsewhere, but it's not critical.


Is asymmetric encryption ever recommended for long-term storage?

Yes, this is a good scheme for medium term storage, as long as it's implemented properly.

A few things to keep in mind:

Common asymmetric algorithms use semiprime factoring as their basis. As such, you can only encrypt data as long as the key, e.g. 4096 bits. This isn't very practical, so normally you would encrypt a symmetric key with your private (or, in this case, public) key and encrypt the data using a symmetric algorithm. So you'd use AES to encrypt the data, and RSA to encrypt the AES key.
Asymmetric key lengths have had to grow at a much faster rate than symmetric keys. It's generally considered that RSA 1024-bit is secure for now, but 2048-bit is more appropriate for anything you're going to need to remain secure for more than a couple of years. If you're looking at storing data for longer than 5 years or so, you're going to need 4096-bit or 8192-bit keys. That's not exactly performance-friendly, but it's a requirement. In contrast, with symmetric encryption, it's thought that a 256-bit key couldn't ever be cracked with conventional methods, even with every ounce of energy on the planet, before the heat death of the universe.
Quantum computers, whilst a long way off, might allow for semiprimes to be factored into their constituent primes in polynomial time, which would break such asymmetric schemes. If you're planning on storing the data for more than 20 years, keep this in consideration.

An alternative would be to have the client encrypt the data with AES-256, then upload it. They can keep their symmetric key on their machine, or derive it from a password using PBKDF2 or bcrypt.


What is the best way to store password in memory (RAM) in Java?

The general guidance is to use a char[], which while not foolproof, will allow you to overwrite the characters in the password once you're done with them, something that is not possible with strings, as they are immutable and continue to live on the heap until garbage collection.

This has also been discussed in detail on StackOverflow.


It all depends on your risk scenario and what you want to protect against.

RDP has had some security issues, and leaving this exposed is just expanding your threat surface. But that might not be a problem for you.

The other problem is about those pesky AD account passwords. You are correct about every point you made. There are default account lockouts and you can have a password policy that enforces strong passwords, and these things enforce a strong security posture.

But passwords are used by people. By using RDP and the same credentials externally as internally, once you get one credential, you get access to both areas (external access and internal access). By splitting up the credentials and/or the technology to enter them, you provide defence-in-depth.

This way, if someone is phished for their credentials, for example, the attackers do not get automatic external access: they have another barrier to breach and do not have an all-access pass.

So, yes, from a general best-practice perspective, putting an additional authentication layer on top of your RDP access makes sense.


Encrypt content such that it can decrypted only by a specific application

True encryption means that a secret will be required to get original data back. Common secrets storage are:

the recipient's brain (something you know)
a smartcard of other HSM (something you have)

As soon as you go away from this secure encryption use case, you fall into obfuscation with 2 common ways:

a custom algorythm - hard to securely setup and test, and hard to protect against reverse engeneering, please keep away from that
a key hidden inside an application executable - hard to change if it were compromised, and hard to protect against reverse engeneering, not really better

If all you need is that Alice and Bob are not required to exchange any keys, you could use a central hub:

application S2 is distributed in such a way that every customers receives a personnal asymetric pair of keys and the central app only stores the public part, ideally the pair should be generated client side, for example during an app initialization
when Alice sends a message through S1, the message in encrypted with a random symetric key, and that key is securely transmitted to the central hub. A UUID of the message is transmitted to the recipient and to the central hub
when Bob receives the message and the UUID, S2 application opens a secure channel (TLS) to the central Hub. Bob is authenticated with his private key as a legitimate S2 owner, so the hub accepts the request for the symetric key for the message identified by its UUID
S2 can decrypt the message and Bob can read it

Limits:

what is controlled is only the ownership of a valid key, if Bob turns evil and decides to sell copies of his keys, you cannot prevent it. Same if he does not turn evil but gets hacked
if Bob finds that you S2 app is not what he wants and uses a third party app that mimics the interface you have no technical way to prevent it - but legal ways may exist...
even if the central hub does not receive the messages, you have full control over S1 and S2, so you could easily get all exchanged messages - you must know it when you present your solution to customers


My certificate seems fine but my TLS fails (Cert not validated)

You client is looking for the server to provide copies of the intermediate certificates and it appears your server is not doing so.  The exact configuration will vary based on your server, but it should be possible to download the intermediate certificates (from your CA) and share them along with your server certificate in order to get to a certificate that the client trusts.

Basically, the client doesn't want to have to (or is unable to) look up intermediate certificates on the Internet.  Thus, you need to provide them so that each step in the chain can be validated.  Some clients will go out and find them or may already include many common intermediate certs, others do not.


TLS_RSA_WITH_AES_128_CBC_SHA on Windows XP

For TLS, the .NET framework utilises the underlying TLS API exposed by the operating system. It does not re-implement the TLS protocol in managed code.

The operating system's TLS stack pulls cipher support from the local cryptographic provider. In XP, this is CAPI (Cryptographic API) which does not support AES. In later versions of Windows the CAPI was replaced with CNG (Cryptography Next Generation) which does support AES.

Unfortunately there's nothing you can do about this if you want to use the native TLS provider or the native HTTP classes in the .NET Framework. You'll have to change over to a managed implementation which includes such features, though I'm not aware of any off-the-shelf product that would help you here.


Penetration testing reported ZERO vulnerabilities. Does this mean my web app is secure?

Automated testing is a good step, but it isn't a replacement for a skilled human ethical hacker to find vulnerabilities. This may be through black and white box testing, code review, and specialized tools like metasploit and custom-written code. However it's done, people with the skills and experience dig far deeper and get many more results than automated tools no matter how good.

It's impossible to give a figure for how secure you are, if all you have done is used automated tools then you have protected yourself from a good deal of the automated exploit tools out there, but a skilled person will likely have a much better chance to find anything.


Vulnerability in popular Javascript Framework (Angularjs)

Angular users: Stop Saving UNSANITIZED User Input.

I have mixed feelings about the answer to my own question. As of Angular version 1.6, the Angular team has decided to remove the sandbox altogether. The sandbox (while not perfect) afforded the user some superficial level of protection against there own choices when building an Angular app. The sandbox was really pretty good and getting better and better. But the sandbox was also never intended to be a security boundary. It was there to try and help enforce clean design principals.

With the sandbox gone, the Angular user is going to be forced to think about the security implications of saving untrusted, un-sanitized, user input. Which I personally think is a good thing. If, and only if, people realize going into that upgrade that it could potentially open wider security issues that they had previously ignored. Hopefully this post helps create some awareness when people are searching 'angular 1.6 security'.

The answer to this question is that Angular has removed the sandbox as of 1.6 to address the fact that users were using the sandbox as a security mechanism where it was never intended to be.

Angular Sandbox Removal Blog post


How can you (anybody) find out the IP address of a single computer inside college

I suppose that our situation is the following: you have detected some undesirable network traffic and you are looking for the perpetrator, so as to, more or less metaphorically, convey to him the inherent unwisdom of his villainous behaviour. The source address of the offending IP packets points to a college; the college uses Network Address Translation so that outgoing traffic from all their students is seen, from the outside, as coming from a single IP address.

(Or, possibly, you are the wannabe evildoer and you want to know what the Long Arm of the Law could do to trace you back. It does not change the technical situation.)

Strictly speaking, the college acts as a kind of anonymizer, since it blocks the actual (internal) IP information. So you should ask the college. They may have detailed logs on network activity, which may help pinpoint the uncivilized individual; for instance, the DHCP logs within the college network could give some information on who had their computer up and running at the time of the indelicacy. There are various sources of such information, which depend a lot on the structure of the internal college network.

Be sure to bring all the information you have on your side; network traces obtained with a network monitor application (like Wireshark or the aptly named Network Monitor) are a must. Also, bring all logs, especially Web server logs, because Web browsers tend to produce a lot of information which can be quite specific to the specific computer which sends the requests (see this page for details).


There exists a policy shipped as part of the distribution service called "Prepare for PCI-DSS audits (section 11.2.2)". This is a policy that has all plugins enabled, TCP scan of all ports, safe checks enabled, web tests enabled, the PCI-DSS setting enabled, and several other things that are less important. I would recommend copying this policy to something else and modifying it instead.

Many of the checks used are local, so you will definitely need to add credentials for an account that has Administrator or root level privileges. For Windows that user should be a Domain Admin or be in the Local Administrators group. For Linux/UNIX the user should have escalation rights, this would be sudo, su, enable, or whatever your distribution uses.

You also need to take into account what type of services the target host is running. Is that server hosting a web application? Web testing is enabled, but it will likely require authentication to use. If your website is using form based auth, then you can go to the 'Preferences' tab, from the drop down select "HTTP login page" and configure it from there. If it's doing Basic Auth then pick the "Login configurations" drop down. Is your server hosting a database? Go to the "Database settings" page and punch in the right values.

You should also look into the various and sundry audit policies. If you log into the Support Center and go to the Downloads page you'll see a link for "PCI Audit Policies". That contains audit policies for many different operating systems. Download the appropriate one and add it to your scan. All of the audits are added, and configured, within the "Preferences" tab. Just pick the appropriate entry from the drop-down box for whatever policy you're using. While you're at it, look through the other audit policies as well. They'll mostly based off DISA STIGs, CIS documents, or FSMA. However, some are written against best practices documents published by the vendors, such as the PostgreSQL audits. Some of the audits may require local customizations so be wary of taking the PASS/FAIL marks as Truth. Keep in mind that the audits are only available to ProfessionalFeed customers (you are a ProfessionalFeed customer right?).

The real take away is that while the shipped scan policy does get you started it is by no means complete. You'll need to customize it to work in your environment. After all,

Alternatively, if you use the Perimeter Service they have much of this already set up and ready to go. This service is sanctioned as an ASV by the PCI Council. A full write-up on using it is available on the Tenable blog.

The information provided above is in no way intended to be taken as official advice and is provided without warrant, guarantee, or good faith. The statements provided do not represent the views of the PCI council, any QSA/ASV, my employer, your employer, the set of all Rorys, this site, any other site, nor the ISP on which you are viewing this message.


Why there is nothing that automatically checks signatures of files downloaded in browsers?

There is such a mechanism - Subresource Integrity.  It allows a web site to specify a checksum for any <script> or <link> element on the page, where the link being provided presumably points off to a CDN, or a partner site, or some other resource that the main web page source doesn't have control over.  You can learn how to use it here.
It wouldn't make sense in the normal context of pages being provided by a single site, because if the download from the site might be untrustworthy, so would any checksum provided by that site.  It's used where there's a demarcation of trust between the page being loaded and the subresources that that page loads.


Authentication with client certificate vs HMAC

I think you summed it up well.

A few additional points beyond the technical security of these solutions:

TLS certificates require management, they expire, etc. You should consider whether you have the resources (can automate to some extent) certificate management. A pretty bad scenario is when IT operations just gets fed up with all the issues and disables cert validation because that way it just works. ;)
An HMAC-SHA1 signature implementation is also reasonably good and you can limit the time window of a replay (and as you said, in TLS it's ok). However, the implementation is more complex than the other too. If it's a larger team that will maintain the code and especially if you have to change the implementation sometimes, there is a good chance that a flaw will be introduced. The other two are much simpler in terms of source code that needs to be written.
HTTP Basic is very simple and may be ok with TLS, but as you said, that I would say is the least secure of the three. Many people still think it's good enough for many purposes though, it depends on what you want to protect against. TLS is considered secure against MitM attackers. I think the biggest advantage is simplicity, there is not a lot to go astray.


Phishing email sent to me within a few hours after a related incident, what should I do?

Best thing to do is to contact your credit card provider and  to block the card.


May be justified to use generic and shared user accounts in order to segregate and reduce risk?

You are right, just giving permissions to each user that needs them only ocasionally is not a good option. Sharing privileged accounts isn´t an option too.

Since you did not specified your environment, I will provide two answers:

Linux/*nix

You could give each administrator the option to escalate to a higher privilege level on his operational account. Tipically, on Linux, you do that by using sudo to run privileged commands. You give such permission to an user by adding it to the sudoers group/file (Ex: https://help.ubuntu.com/community/Sudoers).

The default on most Linux systems is to ask again for the password of the user to allow him to run administrative commands using sudo. However, you may want to ask for a root account password (not the best option since it is a shared password, but may be OK if at least you don´t allow direct root login, making sure one can only use it if he has also a operational account with sudo priviledge).

But if you want even better protection you could ask a different password per user, as  described in https://unix.stackexchange.com/questions/94626/set-sudo-password-differently-from-login-one.

Therefore, using sudo each user will need to know his own password to log in (as operator), and also confirm the password to escalate to an administrative mode when needed. If you want to add extra protection, you can even ask for a second password to escalate to administrative privileges (root or second password per user). But each user will have its own (and only one) user and you will have good traceability.

Windows

You should give each admistrator an administrative account, and set UAC to require the user to enter the password again when running administrative operations. That would be the equivalent of Linux with sudo. However, you can not set a different password to be asked, so using two accounts for each administrator looks like the only option if ou want to really isolate the operational and admin accounts. Take a look on this guide from Microsoft, where they recommend exactly that:
https://technet.microsoft.com/en-us/library/cc700835.aspx

  Separating Administrative and User Accounts for Administrative Users
  For each user who fills a service administrator role, create two
  accounts: one regular user account to be used for normal tasks and
  data administration, and one service administrative account to be used
  only for performing service administration tasks. The service
  administration account should not be mail enabled or used for running
  applications that are used every day, such as Microsoft Office, or for
  browsing the Internet. Always give the two accounts different
  passwords. These precautions reduce the exposure of the accounts to
  the outside world, and they reduce the amount of time that
  administrative accounts are logged on to the system.


Is arbitrary code execution possible using GOT overwrite with W^X enabled?

W^X simply prevents pages from being both executable and writable simultaneously, so an arbitrary write vulnerability cannot modify executable pages. It does not enforce control flow, so any exploit primitive which permits out-of-order execution of existing code has the potential to bypass it. Other attacks such as SigReturn-Oriented Programming, or SROP (on platforms which are vulnerable to it) and Loop-Oriented Programming, or LOP, are often capable of achieving the same thing.

An example JOP exploit can be seen here.


Is LastPass' locally stored One-Time-Password recovery a security problem?

I have actually tried to use account recovery with LastPass just to test this on Mar 5 2014. Lastpass sends you a link good for 48 hours via the email account associated with Lastpass. You need to access this link from a browser with a Lastpass plugin installed. If this plugin was used to access the lastpass account with the email address used for the account recovery, and if One Time Password was enabled, you will be taken to your vault and offered the chance to change your master password. HOWEVER, if you don't change your master password, you will still be left in your lastpass vault, with your various logins visible. You cannot export them without knowing the master password, but you can look at (edit) the various individual logins. Thus someone could take for example your bank login information without ever changing your master password. You might never know this has happened. This presumes that someone has access to your email account, for example, if you left it open on your computer when you stepped away.

I think turning off One Time Password is a very good idea. And the One Time Password in advanced options in the plugin, is PER MACHINE. So any other browsers you use, or portable versions, or if you ever logged into lastpass from someone's computer using their browser and plugin.

I think LastPass should probably disable One Time Password by default, even though some users would probably forget their master password and lose access to their password vault. Lastpass should at least make the One Time Password account wide, not per machine. So you don't have to remember every machine you ever logged from.


According to Chromium's official webpage:

  The Google Chrome Privacy Notice describes the privacy practices that are specific to the Google Chrome family of products

This means, that as Chromium is part of the family of products of Google Chrome, the same privacy notices apply.

Furthermore the webpage also says:

  If you want to learn more about Google Chrome's privacy features you can also check out the Google Chrome Privacy landing page and the Google Chrome Privacy Whitepaper which describes what information is transmitted to Google and why, as well as how to disable certain features in Google Chrome which affect your privacy.

As we previously learned that the same privacy notices apply to all of Google Chrome family of products, this 2 also apply to Chromium.

After further research, I founally found this:

  Browser modes
  You don't need to provide any personal information to use Chrome, but Chrome has different modes that you can use to change or improve your browsing experience. Privacy practices are different depending on the mode that you're using.

And:

  The basic browser mode stores information locally on your system. This information might include:

  Browsing History Information. For example, Chrome stores the URLs of pages that you visit, a cache of text,
  images and other resources from those pages and, if the network
  actions prediction feature is turned on, a list of some of the IP
  addresses linked from those pages.
  Personal information and passwords, to help you fill out forms or sign in to sites you visit.
  A list of permissions that you have granted to websites.
  Thumbnail-sized screenshots of pages that you visit most often.
  Cookies or data from websites that you visit. Data saved by add-ons.
  A record of what you downloaded from websites.

This also might be useful:

  Information for website operators: Sites that you visit using Chrome will automatically receive standard log information, including your system’s IP address and data from cookies or similar technologies. In general, the fact that you use Chrome to access Google services, such as Gmail, does not cause Google to receive any additional personally identifying information about you. On Google websites and other websites that opt in, if Chrome detects signs that you are being actively attacked by someone on the network (a "man in the middle attack"), Chrome may send information about that connection to Google or the website that you visited to help determine the extent of the attack and how the attack functions. Google provides participating website owners with reports about attacks occurring on their sites.

In conclusion, yes. Chromium in fact does share your information with Google.


How can I securely recieve an Orgs secret key? They could just send it to me over the internet?

The client connects to the VPN server using HTTPS, presents himself there in a way they deem acceptable (usually by filling a sign up form, perhaps also performing a payment). The VPN server provides him the data he needs for the connection (that included the preshared key).

Your approach of "created an app that will take any phrase, encrypt it and provide that key to the user" does not work, because you are simply changing the problem of providing the shared key to the user to providing the phrase used to derive the shared key (note: I would consider what you describe a case for hashing, not for encryption).


FreeRADIUS EAP TLS Authenticate based on client certificate CN

So after a bit of digging I came across a commit on GitHub that can do this.

I uncommented virtual_server = check-eap-tls in eap.conf

Then create check-eap-tls in sites-available and symlinked it to sites-enabled:

server check-eap-tls {
  authorize {
    if ("%{TLS-Client-Cert-Common-Name}" =~ /^[A-z.]*@example\.com$/) {
      update config {
        Auth-Type = Accept
      }
    }
    else {
      update config {
        Auth-Type = Reject
      }
      update reply {
        Reply-Message = "Your certificate is not valid."
      }
    }
  }
}

Using =~ instead of == allows you to use regular expressions and in my all the certificates will be alpha with a dot so ^[A-z.]*@example\.com$ works for me.


Why do researcher need to control all C&C servers of a botnet?

In answer to your questions about bots, this depends on the bot itself, I mean it is up to its designer to design how the bot itself receives commands.

The 'traditional' method is ofcourse to connect to a IRC channel and wait for instruction,

P2P is often more difficult to implement (due to NAT/Port Forwarding) and easier to detect (because holes in firewalls are easier to see. )

'Taking ownership' of C&C Servers, it is primarily to ensure that nobody else does, even by accident, and primarily to ensure that a IP address
does not get 'hammered' to much if the IP is allowed back into general circulation (for example, imaging a botnet of 2 million machines hitting a IP
address once per day, thats 1388.8 tcp connections per minute. could have a detrimental effect. )

As for 'not self destructing' the bots themselves, it is because it is not ethical to run code on another machine without the users consent
(even if it is for their own good. ). Its possible that the removal might require a reboot in some cases, or might effect running processes.
(if my machine reboots without my knowledge I am going to go out hunting for blood. can you imagine the backlash if the un-install process caused some damage by accident?)


Would a VPN with changing configs do the same job as different VMs

They protects against different things. VPN protects you from network fingerprinting, while single-use VM protects you from desktop/browser fingerprinting. To be truly anonymous you may need to use both (among other things), depending on your threat model.

If you want to/are fine with establishing anonymous identity (i.e. others can establish multiple related acts are done by the same person, but they can't track it back to you as a person), then you may be fine with just using a VPN, and but hashing to replace VMs.

But if you want to prevent people from linking your actions together, then you may need both.


Protecting data within the intranet from internet

Your question is not well explained. I think you want to replace a messaging service (is this a message queue, and http connection, or something else?) with a database table in the DMZ that's polled by the server in the private subnet, to service a real time web request. When there's a reply it's rsync'd back to the web server.

That will likely result in a large increase time required to service a request. Even polling the database every second will result in latency, and rsync and polling a file system is going to introduce more latency and complexity. This is not practical, it's complex, and it's unnecessary.

A message queue might be more practical, but again they're not really meant for real time communications. You'll have to have your web server sit polling a queue to wait for a reply, taking resources.

A better model is likely to be ensure you have:

A properly configured firewall at the entry point to the DMZ and the private subnet/intranet
A layer that checks requests on the way in, such as a WAF. This can be a piece of hardware or a service. CDN vendors offer a WAF service (AWS WAF, CloudFlare, and Incapsula are some I know of). You can also use mod_security with the OWASP rule set, but it's tricky to tune.
IDS/IPS systems in place
Monitoring so you know what "normal" is for your network
Ensure your internal application has been properly code reviewed and security checked, for example to combat common attacks like SQL Injection. Coverage of the OWASP top ten is a minimum.


There are lots of Artificial Intelligence tools, which even you can't think about... Most simple to understand is explained below :

Facebook is great in face recognition. Your whatsapp profile picture's and your photos on facebook can be easily matched by face hashes. Facebook's facial recongnition algorithms are very good. So the Facial Tags on facebook link you with your mobile number.

Anyways if you are using an alternate number for whatsapp, I can still say that atleast one of your friend who has facebook app. will be having your all contacts linked together under one contact name and that's where facebook is going to get your all alternate contact numbers too. Facebook and whatsapp both do sync. contact numbers. Its not getting synced from your device but is getting from your friend's device.

It will sync. contacts from all your friends and can confirm your name and identity from name saved in their devices. Whatsapp can also read your call logs, sms, browser history, thumbnails, images, sd card data etc...

Spend some time read about permission used by whatsapp and think about if they are really needed by whatsapp...


Is Ignoring SslPolicyErrors while doing SSL Pinning Secure?

TL;DR yes it is safe provided that you trust the means by which you came across the value stored in PUB_KEY.

Here is some background that is needed to first understand the purpose of pinning, and why your scenario allows for ignoring of the error. I'll concentrate specifically on PKI in an ideal implementation.

A private key is a very, very large number that meets certain mathematical criteria. With said private key it is possible to derive a specific public key, but the reverse process is so computationally expensive that it can be considered impossible.

"Applying" a public key to data is "undone" by subsequent application of the associated private key, and vice versa. The owner of a private key can thus freely publish their public key in order to receive messages that, for all intents and purposes, only they can read. Conversely they may publish "signed" data that has had their private key "applied"; this allows recipients to be assured that the data was published by the owner of the private key by checking that "undoing" the signature results in the same data.

This process is all well and good as long as parties to communication are knowledgeable of the ownership of public keys. In such a situation communications proceed as follows:

A -> B
B -> A

However an adversary may exploit the lack of knowledge regarding the true ownership of public keys to act as a "man in the middle" (MITM) by falsely claiming to be the expected recipient:

A -> E -> B
B -> E -> A

A and B are none the wiser. This is where the root certificate comes into play. The root certificate is owned by a trusted third party called a certificate authority (CA) who (i) verifies the owners of respective public keys, and then (ii) uses their own private key (linked to the root certificate) to sign a message to the effect of "Person (A|B) owns public key (X|Y)". A and B, already knowing the public key of the CA can verify that the signature is valid. E can now no longer impersonate A or B without compromising the CA.

The CA's public key is known to A and B through means other than the untrusted network on which they communicate. In the event that A and B are already knowledgeable with regards to the other's public key then the need for the CA is obviated; this is key pinning.

You have "pinned" the public key of your server endpoint by hard-coding it into the value of PUB_KEY.

CAs may publish revocation lists to the effect of "I said that A owns public key X but you should now ignore that" (e.g. if the private key is compromised) and the 'RevocationStatusUnknown' error speaks to that effect.

The 'UntrustedRoot' error says that whomever is acting as the CA in this case is not truly trusted. Who is trusted, and how their keys are distributed is beyond the scope of this answer.


The score would be 0.0. Since there is no immediate impact, the confidentiality, integrity and availability would be set to none, which would make the score 0.0.

Also, it is not necessarily a security issue that user input is saved as-is in the database. The important thing is that it is correctly encoded on output.


Windows CTF/war games/reverse engineering/exploit challenges

Microsoft has annual "Build the shield" contest annually.  https://buildtheshield.microsoft.com.
This might interest you


How different are Lynis and Wazuh solutions?

As the author of Lynis, I suggest using both as they both focus on a different aspect of information security.

OSSEC and Wazuh are focused on monitoring files and the status of the system. Lynis helps you with understanding what can be done on a system to improve/increase its security defenses. OSSEC or Wazuh would be run continuously, where you would Lynis daily (cronjob) and ad-hoc while doing system hardening.

If you are interested in learning more about security tools (who doesn't?), I suggest using the Linux Security Expert project. It is a project I founded to review and explain tools and security concepts. See Lynis (Wazuh is to be reviewed).


What are some common misconceptions about SSL/TLS that members of the general public hold?

Popular misconception: If the lock icon is present, the site is secure.

Reality: No way!  At best, SSL protects data from interception while in transit.  It does not ensure that the endpoint is trustworthy.  There is no guarantee about what the endpoint does to the data once it receives it.  As Gene Spafford once wrote,

  SSL is like using an armored truck to transport rolls of pennies between someone on a park bench and someone doing business from a cardboard box.

Also, there are many situations where the lock icon does not guarantee that data will be secure in transit: e.g., CA failure, organizations that put a picture of a lock icon in the page, mixed content, third-party widgets, sslstrip, and many others.

Popular misconception: If the site looks legit, then it probably is.

Reality: Nope.  The look of the site is not a good indicator of its security.  It is trivial for a phisher to copy the look and feel of the site onto a spoofed site.  This is a case where our intuitions from the physical world lead us astray: it is not easy to set up a fake bank storefront that looks legit, with marble columns and all, but it is trivial to set up a fake banking website that looks legit.

Popular misconception: Anything can be hacked.

Reality: This may not be the best way to think about things.  It leads to a defeatist attitude that says, why bother worrying about security, if it is always destined to fail?  The reality is that some activities are much safer than others, and with a little bit of attention, one can significantly reduce the likelihood of being exposed to security problems.

Popular misconception: Hacking works like in the movies.  Hackers are romantic misfit geniuses who can hack into anything with a few minutes of rapid-fire typing.

Reality: In truth, most attacks come from garden-variety criminals who are trying to make a quick buck by stealing, cheating, and defrauding people.  They're hardly super-geniuses; the primary job prerequisite is a willingness to steal, cheat, and lie.  They tend to be motivated by monetary considerations: they'll go for the quickest, easiest way to make money.  In some cases, they may be associated with organized crime.  These are not people to look up to or admire.

Popular misconception: Wireless networks are insecure.  Criminals sit around in cybercafes trying to hack into your stuff.  However, if you're not using wireless, you'll be fine.

Reality: While some 802.11 wireless networks -- primarily open Wifi and WEP-protected networks -- are a significant security risk, it's not quite that bad.  Most attacks come from someone on the other side of the world from you, not from a sketchy-looking dude sitting on the other side of the cafe.  Not all wireless networks are created the same.  For instance, your 3G connection on your phone is probably considerably harder to intercept or attack than an open Wifi connection.  And, you are definitely at risk even if you are not connected to a wireless network; just because you are connecting over a wired network does not mean you are immune to attack.


Suspiscious HTTP request to nginx server in server log, what is it?

It looks like its someone scanning your server for vulnerabilities. Most likely a bot of some sort. I don't think it's something to worry about, because as @immibis commented, your server is doing exactly what it should do when it receives a request like this.

Public facing IPs are pretty consistently scanned for ways to get in, mostly by bots.


Shenanigans at layer 2 are fairly trivial. Many devices (especially mobile devices) are automatically spoofing their MAC addresses; it is simple to do so on most desktop platforms. By default, if you are sending any traffic on the network, the router may know you are there. By definition, if you are connecting to a wireless network that requires authentication, the access point will definitely know you are there. Whether it knows who or what you are is a different story. The only way to be truly undetectable from a network perspective would be to sniff wireless traffic passively.

replacing crucial informations such as SSL/TLS public key

There are several classic attacks that can be launched from a MitM standpoint; notably, SSLStrip. However, for any service that is already connected to using TLS, you're going to have a hard time. You cannot simply replace certificate information from the server without triggering a security warning on the client, unless it is a poorly written application (e.g. modern browsers are out). That is the nature of TLS; it authenticates the server and prevents an active MitM attacker from being able to do much besides DoS.
There are technologies to detect and prevent ARP spoofing attacks, and these functions are largely implemented in enterprise networking hardware (e.g. Cisco whitepaper). The general concept is that the device uses prior knowledge (previous addresses, DHCP snooping) and looks for suspicious changes in the proposed MAC address mappings or gratuitous ARP packets being sent. If this activity is detected, the packets are ignored and no changes are made to the ARP table. There are also endpoint tools that may be able to work similarly.
If you can't afford to risk ARP spoofing attacks, there's always the option of disabling ARP altogether and using static ARP entries. But in general, properly configured TLS will thwart most risks. Of course, any non-encrypted traffic is fair game to be viewed and modified by an attacker.


Recreating uploads/linked images with imagecreatefrom* php

would even a harmful script that's been run through this be reduced to a broken image?

No, any harmful code in the image is still there.

But if it's secure really depends on what you do with the output of imageCreateFromAny.

On its own, imageCreateFromX doesn't do anything to the image. It doesn't recreate it, it just creates an image resource identifier, so if you want, you could further change the image. But any harmful code inside the image is preserved.

Your exif_imagetype check can easily be bypassed, so it doesn't ensure that the image doesn't contain harmful code.

So if you do not check the file extension, and you use your function eg like this: imagepng(imageCreateFromAny($imageName), $imageName);, then that would be insecure.

  is there anyway to trick one of the imagecreatefrom* functions into executing content as a script

Lets hope not. That would not be a vulnerability in your code, but a vulnerability in PHP itself.

So what is the solution then? How can you make sure that the uploaded image doesn't contain any harmful code? Two ideas come to mind:

As @Steffen Ullrich says here, you can transform the image to a different format, which will most certainly destroy any harmful content
You can search inside the file itself for harmful content. It should be possible to exclude images containing PHP code by excluding <?, <%,  and <script (case insensitive) this way.


Well, I would contact CAs to ask if they would do it. They could do it, and maybe are willing to do it if you pay enough. Any non-critical fields that broswers do not understand will be ignored and could be added by the CA. The question is if they would do it and that only can be answered by them.

Some CPS even mention the possibility of adding non critical extensions (and thos can be private) and NOT adding, of course, critical private extensions (https://www.digicert.com/docs/cps/DigiCert_CP_v409-1-June-2015-signed.pdf - 7.1.2). Its just a matter of wanting to do it.

  Issuer    CAs shall   use certificate extensions  in  accordance  with
  applicable    industry    standards,  including   RFC 3280/5280. Issuer   CAs
  shall not issue   certificates    with    a   critical    private extension.

But probably the right way to do what you want is using Attribute Certificates. You could have a Attribute Certificate Issuer that you control and issue ACs to your SSL cert giving to it the extra attributes you need and only you understand. TLS has support to providing those ACs to your client or you could send those latter on using the already created SSL tunnel, and those could be interpreted by the client as needed.


There are fewer attacks and malware on Mac OS X systems for a variety of reasons, almost none of which having any relation with the notion of "software quality":

There are fewer OS X systems than Windows systems (right now, about 7.5%  of computers involved in Internet browsing use OS X, according to StatCounter), making OS X a less interesting target for malware authors. Developing malware costs efforts and time, so the malware authors want to get a good return over investment. So they hunt where there are the most preys, i.e. on Windows, not OS X.
Malware usually enters a machine through explicit user action, i.e. installation of some software package that turned out to be dodgy. OS X users tend to install less third-party packages, mostly because OS X comes out-of-the-box with more accessories.
In a similar vein, when it comes to supporting hardware, OS X has its own drivers, so the normal Mac user plugs his new device: either it works right away, or it will never work. There is usually little point, in the OS X world, to try to download and install third-party drivers. On the other hand, for Windows, driver download is the norm. This does not mean that third-party drivers are often infected, but it implies that Windows users are accustomed to downloading executables and running them with full administrator rights.
Still on the same subject, Windows has long suffered from something known as DLL Hell, coming from the traditional method of identifying DLL only by a short file name, with no versioning support. This has trained many Windows users to "solve issues" by looking for the faulty DLL name on Google and then downloading it from the first link that arises. OS X, on the other hand, is on the habit of embedding needed libraries in the application, which avoids the issue (at the expense of disk space, since it makes applications larger -- that's rarely a problem with today's disks).
The main characteristic of Windows is its backward compatibility: that which was once running in any version of Windows, will keep running. This has made the system API very complex through decades of accumulation; and this complexity helps malware authors in the hide-and-seek game that they play with antivirus authors. Backward compatibility is much less maintained in the Mac OS world (Apple even switched complete architectures several times, switching from Motorola 680x0 CPU to PowerPC, and then to Intel x86; and support of 32-bit x86 application code can be predicted to be removed at some point).

It must still be said that what makes a machine secure is not really its software, but its system administration, i.e. what the user makes with the machine. Most of the points above are about how OS X users do not behave the same way as Windows users, for a lot of reasons, some of them being historical.


Where's the security when a payment gateway let website handle Credit Card detail

Agreed, from disclosure of information point of view fewer parties in the transaction process the better.

Specifically to eWAY (with I have not used) I assume you are referring to the Hosted Payment solution (See http://www.eway.com.au/Developer/eway-api/hosted-payment-solution.aspx) where a web service is exposed. eWAY do offer alternatives such as the Shared Payment (See http://www.eway.com.au/Developer/eway-api/shared-payment-solution.aspx) which is the redirect to the payment gateway solution but this may not be available in your specific location.

In the case where you are taking payment details you would need to be PCI-DSS (or equivalent) compliant in addition to the payment gateway. Also you should avoid storing any payment details that could be harvested by an attacker.

From a user’s point of view my personal opinion is they would be more cautious being redirected to a payment gateway that they don’t know then using the payment off the web site. Just something to consider.

In my mind, I would use a payment gateway that handled all the payment details for the purpose of offloading risk.

I hope that helps.


Is Certificate-Based Authentication Really Better Than Password Authentication in OpenSSH?

Ensure that /etc/sshd_config contains the following line:

PasswordAuthentication no

You likely have that line commented out, which allows you to fall back to password authentication. Be sure to restart sshd after you change your config.

If you want to install a key from a new computer, you can temporarily comment out that line, install your key after authenticating by password, and then re-disable password authentication.

I also recommend disabling root login:

PermitRootLogin no

(If you only allow public-key authentication, this won't matter as much if the root user doesn't have an ~/.ssh/authorized_keys file, but it is still good to have in case you change your config later.)


Nmap scan of iPhone public IP address shows port 21 open

Typically the IP is shared / NAT'd amongst many devices.
Yes it would be a risk if the port was actually open
It would most likely be opened by an app, so uninstall apps until the port disappears or restore back to factory defaults.


The idea of a Local File Inclusion issue is that you can use the web application to load up files on the filesystem that either shouldn't be available (e.g. things outside the web root) or files within the webroot that shouldn't be loaded up inside a page.

So for example

  http://example.com/file.php?file=main_page.php

in this application the file parameter is used to specify the page that the application should load up, in this case main_page.php.  If the attacker can change it to

  http://example.com/file.php?file=../../../etc/passwd

he can get access to that file from the system, which could be useful for him in attacking the system.  Alternatively he might be able to load a config file which contains application/database passwords.

In terms of vulnerability, any web application language/framework could suffer from this, but PHP does seem to be particularly prone to this and Remote File Inclusion issues.


ssh signature question (no matching key exchange method found)

I'm curious if this is a specific signature (ie. perhaps this is the
  default in certain older versions of SSH) or if this is an indication
  of hackers purposely restricting key exchange to focus on these weaker
  algorithms.

Your attackers are not interested in the key exchange algorithms at all, per se. It doesn’t matter if they are weak in this case or not. The key exchange allows the client to verify the server’s identity, and establishes cryptographic protection for the rest of the connection (the MAC and encryption keys). Your attacker is the client, and doesn’t care about any of that; all he wants to do is try a bunch of common username/password combinations to see if he can get in. Those key exchange algorithms are just common ones that, until recently, were almost always enabled; these in particular:

diffie-hellman-group1-sha1
diffie-hellman-group14-sha1

… are required to be implemented by RFC 4253.


Windows firewall settings to receive UDP and pings

You said UDP or Ping so I am only going to show how to enable inbound ping.

First you need to open Windows Firewall with Advanced Security.

Next find the rule: File and Printer Sharing (Echo Request - ICMPv4-In) (plus the others for IPv6)

Enable this rule.

You can see more here: https://kb.iu.edu/d/aopy or an alternate solution with custom rules from Microsoft: https://technet.microsoft.com/en-us/library/cc749323(v=ws.10).aspx


Can ISO 7816 (EMV) based smart card handle interrupts?

Contact card can. Contact card can even tell terminal to wait and call it again after some seconds and then it can do this indefinitely (21:01).
EMV Book 1, 9.2.2.3.1 Procedure Byte

The procedure byte indicates to the TTL (Terminal Transport Layer) what action it shall take next. Procedure Byte Value 60, the TTL shall provide additional work waiting time.

ICC can instruct terminal to wait by using this byte. The time is calculated as an elementary time unit (etu). A linear relationship exists between the etu on the I/O line and CLK frequency (f). etu cannot be used by ICC to count seconds. It sets duration of I/O line for transmission and reception mode as explained in EMV Book 1, 7 Physical Transportation of Characters and it's follow-up subsections.

During the transaction process, data is passed bi-directionally between the terminal and the ICC over the I/O line in an asynchronous half duplex manner. A clock signal is provided to the ICC by the terminal, and this shall be used to control the timing of this exchange.

I put forward your question to @Steven Murdoch (the researcher behind vulnerabilities in chip and PIN) to know if the reverse happens.

I don't think so, but I'm not aware of situations where it is necessary for the card to wait for the terminal. It's the terminal which is driving the exchange, so the card just waits for the terminal to do the next thing.

I think that something like that could be done but it might be unreliable if the terminal is not specifically designed to support this use case. Normally once terminals have completed their transaction, they turn off the clock so the card won't be able to do further processing.


I snapped my micro SD card into 8 pieces before throwing it away. Should I be worried that someone can get my data?

Should you be worried? No!
Is it technically possible, probably.
Here is an example SD card Xray, although not specifically a SanDisk.

The memory chips are very small and unless you broke that specific memory chip, it's possible to rebuild and recover the data. However, this is a pretty difficult undertaking and not one that most people or even most forensic labs will do, although it is possible.


How to set reverse tcp connection when doing pentesting in VMs?

As far as I know you can configure your VM so that the guest OS shares the physical network interface with the host. In that case if you start

nc -nlvp 8080

the listener is also listening towards the outside world. That should do the trick.


how to find a cryptography scheme (either authentication or encryption) for which some formal analysis of security has not been done yet

I suggest the Cryptology ePrint Archive:

http://eprint.iacr.org/


Droppers are a framework for deploying payloads. This is useful for botnets because the bot master can deploy his botnet without a specific payload, then rent out his network to his customers who provide the payload they want.

Crime-as-a-service. Got to love it.


Is 'looking for all XSS in my code' a solved computer science problem?

I am no expert on formal proofs, but I can at least point you in the right direction.

Searching for XSS vulnerabilities comes down to three elements:

A finite set of untrusted entry point. XSS can only happen, if you process untrusted data. The first thing you have to do is identify all untrusted entry points. In a web application those are usually GET and POST parameters as well as headers. But there are potentially many more indirect / second order entry points like environment variables, untrusted database content, data fetched from untrusted local files or from remote, etc. If those sources are considered trusted or not, depends on your architecture and the attacker types you want to protect against.
A finite set of locations where dynamically generated data is included in a server response (i.e. the website). To trigger a XSS vulnerability, an attacker must be able to create malicious output that is interpreted by at least one browser engine as script code. To identify all locations where this can happen, you have to analyze the output layer of the application and check where dynamically generated output is injected into the website.
All paths between untrusted entry points (1) and potentially vulnerable output locations (2). Performing data flow analysis allows you to find all paths that connect (1) and (2). Each path has the potential to allow XSS, as it connects untrusted input to a potentially vulnerable data output location.

That's the model you are working with. The next step is tracing all identified paths and check for functions that validate or encode the data in a way that prevents XSS. This is tricky, because different types of output locations may require different types of filtering / encoding to protect against XSS. Only the correct method can protect against exploitation of a specific path.

Please note that I deliberately ignored additional protection mechanisms against XSS, which can be considered a second line of defense.

So what does this mean? Yes, you can find all XSS vulnerabilities if you are able to identify all untrusted entry points, all dynamically generated data output locations and all paths between them, including the verification that certain functions protect against specific types of XSS. So why isn't there a single source code scanner out there that will find all XSS vulnerabilities in a complex website?

Fulfilling any of those requirements is highly complicated in practice. Today's web applications consist of a huge amount of different frameworks, containing millions of lines of code. Entry points - especially second order entry points - are easily overlooked and often vast. Data flows are highly complicated, passing through a lot of frameworks and functions. Modern coding patterns (e.g. reflection) make data flow analysis even harder. Judging, if a validation function really protects against a specific type of XSS, can be complicated for certain types of input.

So while it seems to be feasible in theory, there is still no source code scanner out there, that can handle all those difficulties. Which means, no one had yet been able to implement this seemingly simple approach for a wide variety of technology stacks.


How can I generate custom brute-force dictionaries?

Try using crunch - wordlist generator.

Usage is:

./crunch <from-len> <to-len> [-f <path to charset.lst> charset-name] [-o wordlist.txt or START] [-t [FIXED]@@@@] [-s startblock]

-t option allows you to specify a pattern, eg: st%ck^%xch%ng%

Where only

the @'s will change with lowercase letters
the ,'s will change with uppercase letters
the %'s will change with numbers
the ^'s will change with symbols

Running as following:

./crunch 14 14 -t st%ck^%xch%ng% -o wordlist.txt

gives 330000 results:

st0ck!0xch0ng0
st0ck!0xch0ng1
st0ck!0xch0ng2
st0ck!0xch0ng3
st0ck!0xch0ng4
st0ck!0xch0ng5
st0ck!0xch0ng6
...

You can also modify the charset if you think it's insufficient.


Testing Digital signature on an incoming request via Apache

The digital signature of the payload is from Docusign as you've stated in a comment. This payload signature is unrelated to HTTPS and thus can not be verified at the HTTP level in Apache. This means any attempts to use SSLVerifyClient or similar will not work.

From a short look at their documentation it does not look like that DocuSign employs some standardized signature format everybody could verify. Also their API and SDK seem to offer signing only but not signature verification. It might be part of their business model to control this part. But for more details look at their API documentation yourself (maybe I've missed something) or contact Docusign.


Is WhatsApp end-to-end encryption applied to images?

According to WhatsApp's official FAQ, yes.

  Privacy and security is in our DNA, which is why we have end-to-end encryption. When end-to-end encrypted, your messages, photos, videos, voice messages, documents, status updates and calls are secured from falling into the wrong hands.

The WhatsApp FAQ

This would make sense since the underlying Signal Protocol does not discriminate between images or plaintext, so there is no technical reason to send images in the clear.

However, once the content is on your PC it's stored in plaintext, so if your employer has any monitoring software installed on your PC (or the PC of the person you're talking to) they can view the messages/images there.

For more information on when/how media sent through WhatsApp can be insecure, check out this investigation by The Verge: https://www.theverge.com/2019/7/15/20692184/whatsapp-telegram-media-files-android-messaging-encryption


Is there a difference between encryption keys and encryption certificates?

Certificates are used to create a Public Key Infrastructure (PKI). Generally the X.509 form of certificates are used, in which case the PKI is called PKIX, after the standard. The private keys that are part of a key pair are used to sign lower level certificates. This way a certificate can be verified by verifying a certificate chain where each certificate is used to verify the one below it.

PKI requires the use of public / private key cryptography, otherwise known as asymmetric cryptography. An example of an asymmetric algorithm is RSA. AES can only be used with a single secret key and is therefore part of symmetric cryptography: the same key is used for encryption / decryption or signature generation / verification. It's unlikely to the extreme that a certificate contains an AES key.

Encryption certificates are certificates that have been designated to perform encryption. This is performed by simply setting a specific key usage flag. So although the public key within the certificate can be used for any task (encryption or verification of signatures over data) the certificate indicates that it should only be used for encryption (or the function of any other flag that is set).

Asymmetric algorithms are however not efficient, so instead a symmetric key is established using the algorithm, e.g. by encrypting (or wrapping) a random symmetric key such as an AES key. This allows efficient encryption / decryption of the data. To decrypt the AES key is unwrapped in (preferably secure) memory and then used to decrypt the actual data. This is probably what you are expected to do: implement a hybrid cryptosystem using e.g. RSA and AES.

For asymmetric cryptography to be used to encrypt something you need to trust that the public key originates from the receiver. Certificates are used to establish the trust for the public key within the certificate.

Note that these are just the basics. If you have to send the ciphertext somewhere then you are trying to establish a secure transport protocol. That's very tricky, so generally you will be instructed to simply use SSL / TLS instead.


Threat of a Windows XP machine connected to a local network via WIFI (today in 2018)

TL;DR - keep it off the web!

The longer version is that because is no longer supported, it is highly vulnerable and easy to exploit with almost no effort. (To see how little effort, search XP on https://www.exploit-db.com/). Vulnerabilities are being found more or less ad infinitum because of the volume of XP's still used - but there are no new patches being written for those vulnerabilities. With newer OS's, patches are at least identifying weaknesses and actively trying to mitigate them.

If someone is on the same network as you, it is child's play with nmap and metasploit to take over an XP machine. Even with most of your ports closed, XP has lots of attack vectors. To an experienced hacker, it takes a few minutes. I have fully compromised an XP with domain admin privileges in less than 5 minutes, and I'm not a "master" white hat by any means.

If you are behind a NAT firewall or some other means of protection (other than XP's joke of a firewall) it would be "safer," but still highly dangerous and susceptible to incoming traffic, downloading something via Trojan, and other risk factors that newer OS's automatically mitigate with little or no input from the user. This is doubly true if you use something like bit-torrent or other risky applications.

Finally, once your computer is compromised, it's a safe assumption that anything on that specific subnet is also fully compromised, and anything on adjacent networks is at extremely high risk and is either already compromised or will be soon, depending on what kind of malware you downloaded. Once a computer is infected, it serves as a beach head, jump box, landing point, or whatever else you want to call it to attack other computers - but there is NO firewall or protection between them. Domains, by and large, trust other computers on that domain. If this is networked to Active Directory for instance, those credentials will likely work on any other computer in the domain - and if someone compromises your AD server, you are in a very, very, very bad position.


is it possible for another program to find the inputted password in memory during run-time?

Yes, if that program has permission to look at your program's memory. (On Windows and Linux, that means it has to be running as your user account or an administrator)

Note that if a program is running as you on Windows or Linux, it could theoretically already get the password (such as by making itself look like your program and asking you for the password).

  Is there any difference if the password is stored in the stack versus the heap?

It might be a little bit harder to find on the heap, but it's possible to find either way.

  Is there any inherent vulnerability in returning the password from a function un-hashed rather than hashing it as soon as it is inputted?

Not inherently - but the more steps between the password input and the hashing, the higher the likelihood of you making a mistake and somehow exposing the password accidentally.


Could an online anonymizer make Tor without HTTPS safe?

In that case the connection between anonymizer and webserver would be just as unencrypted as the connection between exit node and webserver. It would still be possible to eavesdrop on it.

All you get from this is that you get an additional layer in your onion circuit (the outer layer is the https connection between you and the anonymizer) and that you shift your trust-relation from your exit-node to the anonymizer service.

There is simply no way to communicate fully-encrypted with a communication-partner who doesn't support encryption. No matter what you do, the last hop must always be unencrypted in that case.


Q1. Why two sets of key material?

In section 8:3, they say that we create 2 MAC keys and 2 keys. Isn't that enough safe if the client and the server use the same key and MAC key ? (given that these key are generated from no less than a MasterSecret). I kind of think that it seem a bit overprotected..

No. This is done for a serious reason. This makes it actually harder to attack. There is a class of attack, where you just reflect what one side said back to itself. This is called a Reflection Attack. And by having direction fixed keys, you make that class of attack impossible.
Q2. How to chop up the key block?

When you have the MasterSecret, how do you expand it to create MAC keys and keys ? I doubt that we just take the first N bytes for the key and the rest for the MAC key

Sorry to disappoint you, but that's it actually. There is not much magic here.
You have the key block which is a long octet string. And then you simply chop it up into 6 smaller parts.
RFC
Here's the section in the TLS 1.2 RFC:
  client_write_MAC_key[SecurityParameters.mac_key_length]
  server_write_MAC_key[SecurityParameters.mac_key_length]
  client_write_key[SecurityParameters.enc_key_length]
  server_write_key[SecurityParameters.enc_key_length]
  client_write_IV[SecurityParameters.fixed_iv_length]
  server_write_IV[SecurityParameters.fixed_iv_length]

So that's six parts. And in that exact order. Odd entries (1, 3, 5) are for the client_write direction. Even entries (2, 4, 6) are for the server_write direction.
OpenSSL
Here's the chopping bit in OpenSSL:

p is the key block.

This gets chopped up into:

ms, MAC secret
key, bulk encryption key
iv, initialization vector

Source code from OpenSSL's t1_enc.c:
if ((which == SSL3_CHANGE_CIPHER_CLIENT_WRITE) ||
    (which == SSL3_CHANGE_CIPHER_SERVER_READ)) {
    ms = &(p[0]);
    n = i + i;
    key = &(p[n]);
    n += j + j;
    iv = &(p[n]);
    n += k + k;
    exp_label = (unsigned char *)TLS_MD_CLIENT_WRITE_KEY_CONST;
    exp_label_len = TLS_MD_CLIENT_WRITE_KEY_CONST_SIZE;
    client_write = 1;
} else {
    n = i;
    ms = &(p[n]);
    n += i + j;
    key = &(p[n]);
    n += j + k;
    iv = &(p[n]);
    n += k;
    exp_label = (unsigned char *)TLS_MD_SERVER_WRITE_KEY_CONST;
    exp_label_len = TLS_MD_SERVER_WRITE_KEY_CONST_SIZE;
    client_write = 0;
}

I don't speak C too well. So I don't really get it.

I don't understand the indexing into p.
I don't understand why they only select one half of the keys. Each end needs both sets. One set to write to the other end. And one set read what the other end said. -- I guess that chopping happens elsewhere.


My company policy states I must put all passwords in a password safe shared with management. Is this secure?

None of the reasons you've given are valid reasons for escrowing your password.  There's only a couple valid reasons for escrowing any sort of "authenticator" information.  A couple others have touched on these, but I'll try to clarify a bit.

Encryption Keys:  It makes absolute sense for the organization to have access to escrow copies of your encryption keys.  After all, the data you're encrypting (provided you're only using your company's encryption for work purposes, of course) is their data in the end anyway.  So, they need to retain access to that data in the event you lose your key or you are separated from the company.  However, the encryption key should not be the same key you use for digital signatures.  Also, they should not have actual access to your authenticator - the passcode you use for the key.  Instead, they should have their own escrow key that works with their authenticator to decrypt your data.
Failsafe Accounts:  It also makes sense that the organization should have backup copies of credentials necessary to access an Administrator-level account in the event the System Administrator's own account is locked out, or they depart the company.  However, the credentials should not be for the System Administrator's own account.  They should be for a local system account whose sole purpose is for emergency use.  To that end, the account should also never be used for non-emergencies and its usage should be closely monitored and alerted.  Traditionally, credentials for accounts like these are sealed in tamper-evident envelopes and stored in a secure, physical vault.  It's conceivable that there may be digital equivalents, but I personally wouldn't trust those without a thorough review.

There's two big reasons why it's a bad idea for management to have your password.  The first reason is potentially very bad for you, as it could end up causing otherwise unnecessary work for you if things go wrong.  However, the second actually turns this around and makes it potentially worse for the company than it is for you if things go really wrong.

Potential For Abuse:  The obvious one - managers now effectively have unrestricted access to the systems, regardless of whether they should, with the same privileges you have.  Most simply this means that the managers may leverage this to do things on the system that they otherwise should not be doing.  This also leaves the potential for them to bypass your position whenever they want to rush a particular change along without following standard procedure.
Loss of Non-Repudiation:  Once someone else has your credentials - and, especially in a case like this where it can be proven they do - they can impersonate you on any systems where those credentials are valid.  This makes it difficult to definitively prove that any actions taken by your account were actually taken by you.  If a manager does decide to use your account, and ends up royally screwing up the system, it won't be very easy to use you as a scapegoat even though your account is in the logs.  Worse for the company is, if you do something to royally screw up the system while your managers have your password, they'll have a harder time proving that it was actually you that did it.

TL;DR: There's no good reason I can think of for management to have any of your passwords.  As for the reasons they've given:

"If you forget your password..." another System Administrator can reset it for you.  Or, management can "break the glass" on the emergency account (see "Failsafe Accounts" above) and do it themselves.
"If you turn evil..." again you can be locked out by another System Administrator, or the emergency account.


Are there any risks in wrapping asymmetric encryption in symmetric?

Password-protecting a key, either symmetric or asymmetric, is a common practice. See the question Encrypting With Passwords - Encryption of Key vs. Data for an example.

One problem is that users can choose weak passwords. This can either be, as you note, the same password that they use to authenticate to the site, or it can just be a generically weak password. Using client-side authentication password hashing to keep the server from knowing the user's password can help.

The LastPass password manager seems a similar use case to what you are preventing. LastPass uses 5000 rounds of PBKDF2 with SHA-256 on the client to prevent LastPass from knowing your master password. Performance is a problem with this solution as you need to do enough rounds of hashing to prevent a brute-force attack. As client machines tend to be much slower than server machines, this will be painful. This isn't a problem in the LastPass user model because users are willing to be patient for authentication to LP. You'll need to determine if the same is true for your user model.

A second problem with this solution is that recovery of a lost password encryption key is impossible. While this is a security feature, it may turn out to be a problem for your users.

One advantage of such an encryption scheme is that if the user changes their encryption password, you just need to decrypt the key with their original password and re-encrypt it with the new one. No need to decrypt and re-encrypt all of the data.


Is it safe to accept a file upload without any file extension?

The extension itself should not matter. It would be good to figure out the MIME type to know about the content instead.

In terms of security risks in terms of file uploads, please see also https://www.owasp.org/index.php/Unrestricted_File_Upload


How to prove my identity by GPG signature on a file?

You can either go to a certificate signing party or get an X509 certificate for you PGP key and get it verified by a CA trusted by all parties involved.