Justifications for disallowing torrents as an IT Admin

Don't quote me no this, but I don't think there's any jurisdiction where using torrent is illegal. There are many jurisdictions where downloading copyrighted files are illegal, and while torrents are often used to distribute copyrighted files, there are many perfectly legal files shared through torrents. For example, many major Linux distros distributes their installer images as torrent, some public government data are distributed through torrents. Listen to your users and check if any of them may have legitimate uses for torrents.

From organization/company perspective though, there are a number of reasons why you might want you limit torrents if it's not necessary for day to day operations of most people. Remember that since you are the network administrator, you set the policy that you want to enforce, based on the needs of the organization and the culture that you/the leaders want to develop in the company.

Some companies want to develop an open culture, where most employees have minimal restriction/monitoring on what they do on their workstation as long as it doesn't disturb the daily operation of the company. Many such companies might have acceptable personal internet use policy. You should work with the leaders of the company to develop this policy, and define what kind of personal use is acceptable (e.g. accessing personal email, downloading files for personal use, using printers for personal use). Alternatively, if the leaders want to develop an informal culture, they may want to leave such policies unwritten and leave them to be i-know-it-when-i-see-it until it actually becomes a problem (e.g. excessive internet usage, unwarranted slow downs, receiving copyright notice). Within this culture, even if your country doesn't necessarily enforce copyright laws strictly or even if there's no such laws, I would still highly recommend developing a policy for respecting copyrighted materials anyway as a matter of good business practice. You may also want to develop a policy where users must agree to subject personal files on company equipment for virus scans or other searches when demanded, these policies may or may not sufficiently mitigate the risks of allowing personal internet usages.

Other companies have a need to develop a more restricted approach, where users have to be able to justify every network protocols they use before they are allowed to use it. Within this culture, you need to listen to your users and make sure that the network restrictions doesn't hinder them from doing their daily tasks. If there are network protocols that the users need to use that you just don't want to/can't support, then develop an alternative plan with them or shift the responsibility of that task to someone else. When you want to develop this culture, you want to white list the network protocols that are permitted for each users and possibly even whitelist the network destinations.

Remember, good security policies should be an enabler, not a hindrance to one's work. Good security policies and controls allow people to do things that otherwise would have been too risky to do. Listen to your users and the direction that the leaders want to set for their company. Based on that, figure out what network protocols they use, develop a policy around that, write them down in company manuals, and then enforce that policy. Don't try to enforce unwritten policies, as you will just alienate everyone; having the cooperation of those that are subjected to the policy are crucial to the practical viability of a policy.


What to do to increase a custom authentication cookie's security?

Use the SameSite flag to prevent CSRF attacks.
Use cookie prefixes to prevent cookie clobbering.
Use a HMAC to prevent cookie tampering. You say you have prevented this using a salt. It is unclear what this means, and if it is not a HMAC it is probably not the correct way to prevent tampering by the client.


I was in the same boat as you are about a year ago. The way i got around it is by getting my hands dirty into the business. I am not sure what kind of role you aspire to be ( manager, researcher, penetration tester,etc). You need to figure that out first.

IMHO you cannot be a info sec manager without being good at say network security, pentesting, Linux admin etc. I believe a solid way to learn would be to take some certifications.

I personally did OSCP which teaches you alot. It has a much higher bar to clear as it is extremely lab driven. It takes hours and hours of hard work and patience  to be a good info sec professional. If you don't want to pay for the course, how about spending some time hacking a couple of free vulnerable systems especially designed for pentesting novices.

OSCP

VulnHub

All said and done I am not a big fan of meetings/discussions but others maybe.

May the force be with you! Good luck.


support the new Brotli compression algorithm over HTTPS only.

In theory yes. In practice Chrome will currently accept brotli compressed answers with plain HTTP too, even though it does not announce support for brotli in plain HTTP. Firefox only supports answers in HTTPS.

  If my understanding of BREACH (and the related CRIME attack) is correct, compression is unsafe over HTTPS.

This is a wrong generalization. The BREACH attack only affects dynamic content which contains secret information like CSRF tokens which the attacker likes to guess. It works only if the attacker is able to reflect own data into the original content like in case of reflected data from filled in forms. The attacker must also be able to detect changes in the size of the compressed content, i.e. using passive sniffing of the connection (classic BREACH attack) or through timing (HEIST attack). It is still secure to compress content where no reflection is possible and of course content which contains no secrets the attacker likes to guess. This especially means that compressing static content is safe.
As for the CRIME attack it is enough to disable TLS level compression which current browsers have done already. CRIME has nothing to do with content compression in HTTPS.
See also Is gzipping content via TLS allowed.


Verification and authentication flow for X509 code-singing certificate

If you are storing a trusted CA's public key, then you may not need to do any more. This assumes a couple of things:

The CA will never perform any revocation
All of the signatures you check will be generated by the same CA

It is also important to be aware that the CA will expire at some point (as indicated in the CA cert), and there may come a point that you stop trusting this CA. You should have some way to stop your code from trusting things signed by the CA.

You don't really need to go the full route unless you are dealing with many potential intermediate CAs, signed by a few roots (that you still hard code). Because you will only evaluate the intermediate CA when you see it, you will need to perform a full set of verifications. What you gain by going this route is that you can trust many more CAs, and you get to check to see if anything in the chain has been revoked.


Yes.
It doesn't matter whether the host is a Mac or a PC. DBAN is it's own operating system, and works the same, regardless of hardware. DBAN overwrites the entire hard disk multiple times with zeroes and garbage data.
Recovery is impossible if the process was completed.


Does TLS fallback only keep from downgrades to SSLv3?

The TLS_FALLBACK_SCSV draft RFC protects against any downgrade attack. When a client's first handshake attempt fails and it falls back to a lower TLS version (including but not limited to SSL 3), it will include the SCSV, and the server can know that the client wants to support a higher version but was prevented from doing so. If the server also supports a higher version than the one the client fell back to, it will generate a fatal alert, since there should be no reason for the client to fall back below the server's highest-supported version.


How can the passphrase matter besides the very most obvious patterns?

You defeat password brute-forcing not by the resulting pattern that is created but by the randomness of how the password was created.
password1 is easily guessed because 1) it's used often, so it's in "Top 100" password dictionaries, and 2) it follows a normal pattern that people often choose (dictionary word followed by a digit). There is little randomness in how it is chosen.
If password1e is in a dictionary, and you use it, then the game is over. The fact that you have added one small addition to a normal and expected pattern adds time to guessing, yes, but if the brute-forcer tries this pattern, then game over. You've taken a known password and added a character. This has very low randomness, and it's an easily guessable pattern.
If your password aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaapassword9 gets leaked, I now know your password pattern and I can design a brute-force approach for your accounts. Game over. It's long, sure, and if I'm trying to guess it character by character, it will take a long time. But once I know your pattern, the length is meaningless.
Password patterns are like hiding your house key under the mat. They work until someone knows where to look, then every password that uses the pattern is useless against this attacker.
In security, there is a concept known as Kerckhoffs's principle, which says that a secure system should be able to remain secure even if an attacker knows how the system works.

If I know your password pattern, then your password is not secure
If you use a random password generator, then the password is secure even if every attacker in the world knows that you do that
If you use 4 randomly chosen dictionary words, your password is secure for quite a while due to the size of a typical dictionary
If you use 4 words that you choose yourself, your password is not so secure due to the small number of words the average person will think of (and yes, there is research directly into this, and the list of words is shockingly small)

The more randomness there is in the selection of a password, the more secure it is. Length does help, but length can be defeated by a known pattern.


Active directory penetration testing is an entire field of study with many attack vectors. BloodHound by SpecterOps looks for common active directory misconfigurations such as stale objects, incorrect ACL/DACL assignments, delegation issues, problems relating to trusts between AD forests and many more.

However, if stealth is a concern, BloodHound is quite noisy so an IR team or someone in the SOC could detect this so it is a risk to run that tool in a high security network. However, I still use it during engagements as the typical response time for this in my experience is 1 hour (it queries the domain controllers to get this info which is typically considered crowned jewels in enterprise, highly monitored).

This is typically enough time for me to pivot and establish persistence on another machine. BloodHound gives you a graph defining the shortest path to compromise (as they call it) of the domain (if possible).

There are also many old school tactics for compromising AD misconfigurations, I'll be attaching several links below. I hope you can find inspiration for a cool pwn in one of these links.

https://www.slideshare.net/dafthack/pwning-the-enterprise-with-powershell
https://www.slideshare.net/AndyRobbins3/six-degrees-of-domain-admin-bloodhound-at-def-con-24
https://www.slideshare.net/harmj0y/i-hunt-sys-admins-20
https://www.slideshare.net/harmj0y/not-a-security-boundary
https://www.slideshare.net/harmj0y/ace-up-the-sleeve


What are the risks of making ether-wake available to all users?

That utility needs root access because it uses a raw ethernet socket. In a similar way, ping needs root access, as it also uses raw sockets. The difference is that (on most systems) ping is suid-root so any user can run it.

If you're happy with non-root users generating these packets, you can make etherwake suid-root, or use sudo as you suggested. There is a small technical risk, in that etherwake may have privilege escalation vulnerabilities, but given that the program is quite simple, I'd find that risk acceptable.


Virtualization as a layer of security for desktop computers?

It really depends.

To go through your points:

Depending on the host and guest operating systems, you may need additional security here. For example, I have a couple of Windows VMs from which I can remove any dodgy programs onto the samba share without too much fear that the linux host will be infected by the presence of these files. However, there is the possibility that a virus exploiting a vulnerability in the linux samba daemon could well exploit my host (I just accept that risk).

One solution to this is rather than using disk images, write the virtual machine disks directly to disk, i.e. to a partition. This means IO isn't virtualised, which is faster, and it means you can literally modify the filesystem direct from the host. Of course, your VM software must support this.

A third alternative is to mount the filesystem. qemu, for example, is capable of mounting qcow images and retrieve content that way.
Yes, absolutely. Very necessary. Must happen. You should do all you can to defend the guest from attack because it may well become compromised.

Another point to make here is that you have one additional defence - every so often, take a known clean snapshot of the system. Then, if you get an infection, roll the system back.  Of course, you must know you've been infected and not back up an infected system.
If you really want to revert the system after each browsing session, you will have a lot of extra work to do. You'll need to have sessions where you patch the baseline and do not browse, and browsing sessions which you roll back after to that baseline.

You're certainly not the first to practise this kind of setup. The security researcher Joanna Rutkowska did an interview with Tom's Hardware detailing her virtual machine setup and the concept of having different levels of virtual machines she cared about, with increasing security setups, and doing different browsing on different machines. It's a very interesting read; for me, it's a little on the paranoid side.

Now, to virtual machine security:

A compromised virtual machine has whatever access you give it to the local network. This could be nothing (safer) or it could be limited access to services on the host (SMB, SSH) or it could be all access. The point is, you are increasing the attack surface potentially, especially if you ignore point 2 in your question. If you're using NAT, be aware both your virtual machines share the same IP to the outside world, so it might appear like your host is doing things it shouldn't.
There is active research in red pill techniques, i.e. escaping the hypervisor. I am not qualified to say exactly how likely these are to be in the wild now, but I can tell you detecting being in a virtual machine is not that difficult and like anything else, the more prevalent the virtual machine becomes, the more appealing red pill code will be.
Some attacks are not prevented by virtual machines. Session hijacking, cross site scripting attacks. Anything that attacks the application layer of the web site or application you're using rather than trying to attack your host may be something you overlook.
The host can still be attacked through alternative mechanisms (flaws in any network related services or indeed the content you pull onto it "securely").

Is it secure? That question can only ever be answered in the context of what you want to protect. Personally, for me, I weighed up the value of the information I have to protect versus the effort of maintaining several or one virtual machine(s) and decided the maintenance burden was probably not worth it. My host is reasonably well protected as is and I think it adds additional complexity to my setup. I prefer to defend one point of entry, not two or three. However, assuming you are skilled at maintaining all your virtual machines and have a need for this level of security, I would say the separation from the host and the ease with which you can roll back machines make it an addition to your defences.


Is there any risk in allowing more failed login attempts before autobanning for a longer time?

A lot of people have very short very weak passwords - 40% of all users share the same 100 passwords, 14% share the same 10 passwords (see article). So even a 10 or 20 passwords may suffice for an attacker trawling multiple user accounts. Hence the low cutoff bar.
If the user is legit and has simply mistyped their password several times, they have probably forgotten it. Some organizations like to be directly contacted for password reset, despite the possible support overhead.
While I personally like exponential time-locks; unless an organization has 24/7 tech support, timelocks will turn into normal user lockouts on a weekend. Additionally a distributed attack across multiple users at once may rearrange the exponential delays sufficiently that, on a bell curve, some user account will be cracked well before the exponential delay for a single user would imply.
The organisation may assume that a denial of service is either sufficiently resolvable  or unlikely enough that a DDoS lock out of all users is a low concern.
An organization may feel that the user's access to their service is a privilege and the user or service's information is more valuable than the user's ability to access it. Hence a priority toward operational security instead of user convenience. Afterall the actual users are rarely invited as direct stakeholders in the software design workshops.
Initial solutions for Points 1 - 5 were made on early computer systems and then often copied as "good enough" for computer systems made decades later. The original systems involving remote login were military and university projects; where the user was a supplicant not a customer.


Helping developers find logic and authorisation flaws

This has been covered before, but in my opinion, the best way to help developers find flaws that could lead to exploitation is to teach them to exploit code, teach them how to execute an SQL Injection attack or a direct object reference attack. Set up a capture-the-flag competition in-house with developers using their new hacking skills to break the sort of code they're used to writing.

Once you actually see how the exploits work, and once you've spent some time exploiting it yourself, then places in code you see that are exploitable start to draw attention to themselves. Once you've been trained to look for these flaws as an attacker, you can't turn it off. You see them everywhere. And the more time you spend "hacking", the brighter they start to show up. What yesterday was a time-saving trick now becomes an stepping-stone to privileges escalation. It's just a matter of perspective.

Presumably your developers will never have a use for the hacking skills you teach them, but you want them to have those skills anyway. It completely changes their point of view as developers and changes the type of code they produce.


How do I know my tools aren't compromised?

Actually, you cannot. Even without speaking of an actual compromise, from a security perspective you may assume that your application already contains bugs which can be at least be as effective than a software compromise.

That's why, when building a secure system, your security must not rely on a single tool. Instead, you must use a layered security approach, the final application being in the center, adding several layers of security over each one with the following approach:

The outer layer N+1 is in charge to control the security of the inner layer N,
While there can be a way to pass data/session from layer N+1 to layer N (think about proxies, firewalls, etc.), there must be no easy way to pass from layer N to N+1.

Such scheme can be achieved:

On a host using a combination of all different segmentation tools provided by you OS (each service running a different user with minimum rights, use of jails/container/..., etc.),
On a network using proxy, firewalls, NIDS, monitoring, etc. (it might be a good idea to use slightly heterogeneous platforms)

This will provide you two advantages in case of any kind of backdoor would be used:

Unusual activity has by far more chances to be detected since it would at least require some time before climbing up the layers,
If you set your system right, the flaw will be limited to the area actually accessible to the backdoor, all the rest of the data will remain safe.


two-factor authentication suffix code in the password

Let's assume that a user has knowledge of its username, password (of course), and has access to its two-factor authentication (2FA) codes.

From the server end, having the password+verification_code in the same field will incur a slight overhead in extracting the password & code from each other, provided that we know that the code is the last 6~ digits of the entire string. We would have to decrypt it, split, check against the database, then permit the user. But I do see an upside to this, skipping one hop of user interaction and connection. Which means cutting the authentication period and communications to close to half.

Which to me seems like a convenience for the end-user, and what do they say about convenience? Especially when it comes to security.
Convenience increases risk.

  Which approach offers better security?

Well, when it comes to having two separate forms, one for username/password and the other for the 2FA Code, this alone offers segregation, a distinct line between two different forms for different purposes. Having segregations are extremely valued in this field.

It is good practice for an implementation that will provide a different session or a unique token upon successful credentials being POSTed. This brings us to the next step, a new page/form that prompts the user for the 2FA code. This very practice is about sending two pieces of key information separately, one being something you know like your username/password and the other being something within your possession like a 2FA physical token or an authenticator app


What are the best practices for maintaining privacy on a non-jailbroken iOS device?

In addition to the other answers, here are more tips :

if you must use social media, use either their mobile site or a third-party client. Social media is evil by definition as their way of making money is by reselling personal data, but third party developers couldn't care less about the social media site making money, they just want you to buy their app and will respect your privacy in most cases. Make sure you trust the developer, a concrete example of evil third-party apps would be the endless Snapchat screenshot apps coming from unknown developers often with Chinese names; if you want to see the damage done by these apps, search for snapchat leaked (NSFW); if you can't find a client you trust just don't use that social media service at all.
don't install all the apps you can see. For a developer, having their app on your device should be a privilege, not a right. There is really no need to install the latest clothes store's app or the new train/plane ticket comparison app. News app are evil as well, there is really no need for an app to read news, Safari can do so just fine, both for buying clothes, reading news and about 70% of what you're doing on your phone.
prefer paid apps over free ones. Free apps mean either there is advertising (your privacy is violated by the ad companies) or that you become the product (your privacy is violated by the app's developers themselves). Both are equally bad. Paid apps on the other hand have no advertising, so assuming you trust the developer you should be safe.
again, use Safari (in private browsing mode) whenever possible. Installing an app should be only as a last resort and that should mean you trust the developer entirely, which should rarely be the case.
finally, if you have the technical means and knowledge to do so, consider passing all your device's traffic through your network (via an HTTP proxy, VPN, or custom APN; the latter is very costly but means the carrier routes all the internet traffic from your mobile plan directly through your network, avoiding the need to configure a VPN on the device itself). You'll see, in addition to the obscure traffic caused by the device itself, quite a bit of analytic and crash reporter traffic. While they're less evil than plain advertising, they also should burn in hell. Block them at the proxy level (which can filter based on the hostname even with HTTPS) or at the firewall level in the worst case.


Is it unsafe to keep multiple versions of a KeePass database?

Short answer:
it's probably fine, but make sure to regularly delete really old files.

Long answer:
There is a few reasons why it could be a problem. To illustrate some cases, let us assume an attacker gets hold of all these files, rather than just one (i.e., the most recent one). What could cause your approach to be less secure? Here are some hypothetical possibilities (that could become real in the future):

There was a vulnerability in an earlier version of KeePass, which was since patched, but that stored data in an insecure way. This could lead to the passwords up to that version being compromised, while deleting the older ones would have no effect.
KeePass encrypts the passwords, but has some cryptographically weak way of storing the passwords. For example, lets say it does not use randomized encryption. This means that an information leak exists: the attacker could see when accounts were added or removed, by looking at the difference between files (assuming the order of the passwords remains the same).

The KeePass wikipedia page only says that AES or TwoFish can be used as cyphers. These can be considered secure, but the bigger question for the above is how they are used. There are many more potential cryptographic vulnerabilities that could exist (just look at the problems we saw in recent years with SSL/TLS). However, those are likely to be theoretical in nature, and likely to affect both the case where you only have one file, and the case where you have multiple. Thus, unless you're storing extremely sensitive passwords, keeping a few backup files probably doesn't hurt.


Because < and > are encoded, ending the anchor tag and adding a new tag won't work. However, if " quotation marks aren't encoded or filtered out, you can definitely still get XSS. For example, example.com/"+onclick="alert('XSS!') as a URL input will generate the output <a href="http://example.com/" onclick="alert('XSS!')" target="_blank">.

The onclick alert is the easiest way (EDIT: as @pineappleman points out), but you could also add other events (such as onmouseover) and could display your own content in front of the page using CSS, which could allow an attacker to influence victims into doing things that they would not want to do (think clickjacking, but on the vulnerable page directly instead of via an iframe of that page).


If I understand what your asking correctly. Then the limitations are not imposed by the sniffer itself, but are limited by what it can see physically going past on the wire.

What you'll be able to sniff is mainly limited by the placement of your sniffer and the type of network you are on. For example on a network using a Hub you'll be able to see all the traffic being sent to every machine connected to that hub, but on a switched network most likely you'll only be able to see the traffic that is destined for you.


Is using online SQL prettifiers considered safe?

A quick test shows that it is indeed sending queries to the server (unencrypted as well) rather than formatting locally with JavaScript, so yes, you should stop using it for anything you want to keep secret. Even if it were entirely JavaScript based I'd recommend against using it since it could be changed at any time.

Whether or not it's necessary to keep your schema secret is debatable (see here and here), but just because it's not necessary to keep something secret doesn't mean it's a good idea to go around telling random people. If you don't care if everyone knows your schemas and queries then go ahead, but if there is even minimal reason to keep them private I'm sure there are alternative offline formatters.


Automated Malware Analysis Tools as a standalone

Perhaps you can try Limon sandbox. (for Linux malware)
https://github.com/monnappa22/Limon


Help identify a simple, reversible cipher/encryption algorithm

It looks like DES.
Arbitrarily using a Key of hex    0000000000000000
and an initialization vector of   0000000000000000

The value 0000000 becomes  01a4f7bc5f3aa9ee
but value 00000000 becomes de8d55142b18deb7472b8bbb294d3f3d

I have no idea as to the correct Key and IV.


Site exposes user's GPS location through EXIF data

Is this actually considered a security risk, or are they right that this is just user error?

  Is my approach of releasing a blog post and an application with it that can tell you if you are vulnerable or not the right one to do, since I couldn't get the developers to plug this hole?

  Should I be concerned that if I make my findings public it can lead to a surge of malicious use, which I'm worried that could lead to real life stalking and abuse of some of the members of the site, or am I just worrying too much?

The developers not wanting to fix it does not make the issue go away.  Let's examine two possibilities for your first question:

If users of the site agree with the developers and don't care after it has been explained to them, there was no harm in your blog post, or in anyone else using your code.

If users of the site disagree with the developers and do care, they can now a) petition the devs to change their minds, b) stop using the site, c) implement scrubbing on their end, or d) take other actions to fix the issue.  The issue was already present, so your blog post has lead to a better situation for those users.  The only way this wouldn't be the case is if you're assuming no one else has, or ever will, discover the issue, and history says that's a poor assumption to make.


What is the best practice for encrypting and storing temp data on client?

Threat modeling.

Who are you attempting to hide the data from? The user of the mobile device? If the admin needs to recover the data, why not just keep it on the server?

If you don't care about encrypting over the network, you don't care about the privacy of the data, so we need to understand what business purpose is served by encrypting on the device, if we are to provide a useful answer.

When you talk about a symmetric key protected by a public key, you are basically re-inventing https (TLS), in which case, just use that instead of http, and rolling your own.

If the client picks the symmetric key, it could decrypt the files locally, so you gain no protection there, and since the files aren't encrypted when originally sent over the network, I don't understand the business value/requirement to store them encrypted on the end device. A hostile end user could just capture the unencrypted files as they were sent.

If OP can flesh out the question with the reason for the requirement, we might be able to give better advice.

In the most abstract, what you describe would "work" but wouldn't really be protecting anything in any meaningful way.


What are the disadvantages of using public key cryptography when encrypting files?

Your friend is correct in that private key encryption is not the tool for the job. This answer on Cryptography.SE does a good job of explaining why. Some highlights:

  Any public-key encryption schemes is bound to increase the size of the data that it enciphers.

  While there are more efficient schemes, it is safe to say that a symmetric scheme is orders of magnitude faster and less power hungry than an asymmetric one, at least for decryption.

Private key cryptography is used when the person doing the encryption is different from the person doing the decryption - a situation symmetric cryptography can not handle if the parties can not easily exchange keys.

When private key cryptography is used for transfering larger volumes of data (like in TLS), you normally first encrypt the data with a random symmetric key. Then you encrypt the symmetric key with the recievers public key so that they and nobody else will be able to read it and decrypt the data.


How long should the maximum password length be?

The answer to this one, like a lot of questions in Security is "it depends".

There's several factors to consider when looking at password length. First up is some of the things that a long password is designed to protect against, which is generally a brute-force of password guessing attack (online or offline).

For online password guessing, if you've got a relatively aggresive lockout policy (eg, 3 incorrect attempts and then an indefinate lockout) then attacks against a single account will be unlikely to succeed unless the attacker has a good idea of what the password is going to be.

If you're looking against attacks on a large population of users with the same lockout policy, where the attacker can work out the usernames (eg web forums), then the most important element is probably that the passwords used aren't any of the really common ones.

As an aside,  one thing to watch for on the account lockout side, is that aggresive policies here for on-line applications can make a Denial of service attack quite easy, without additional countermeasures.

If there's a risk of offline brute force then password strength becomes more important.  the problem here is that improved processing power and methods of attack make this a moving target in terms of strength.  Realistically I'd say that you'd be looking at 10+ characters and strong enforcement that passwords aren't on common dictionary lists (like @andy says passphrases are a good option here).

Another factor to consider here is your user base, and how the application is used.  In some cases, I'd say that very strong password requirements can actually lead to a less secure application.  If you have an application where the users are in the same place (eg, a lot of corporate applications) and you make the password policy very "strong" (both in terms of password length and rotation requirements) then it's likely that users will start writing down their passwords, which probably defeats one of the goals of security for that application in the first place.

One good source of a lot more information on this is a book called Authentication: From Passwords to Public Keys


HTTP Content-Security-Policy Nonce and Caching

If the nonce must be unique and unpredictable, then one would need to disable all server-side (i.e. Varnish, Cloudfront, etc) caching on the pages that use <script nonce="XXXXX">. Correct?

Yes. You always have to disable caching on anything that is dynamically generated (i.e. comes from a script). Since you can't serve unique and unpredictable random values statically, it must be done from a script.


What does "8.11 Encrypt or sign files into an archive" do?

OpenPGP encryption is only defined on single files, there is no official way to define something like a folder structure, not to speak of permissions, file owners and other thing one might want to keep when encrypting folders.

The "unix way" in working around this is to create an archive, which is subsequently encrypted, which is explained in the GnuPG manual chapter "8.11 Encrypt or sign files into an archive" you referenced.

gpg-zip takes a folder as input, puts it into a tar archive which is finally encrypted, keeping an otherwise similar command line interface GnuPG does. Running gpg --list-packets on gpg-zip's output reveals what GnuPG is doing here (I used symmetric encryption here, but it works the same way using public/private key encryption), encrypting /tmp/foo while being in /tmp:

$ gpg-zip --symmetric foo | gpg --list-packets
:symkey enc packet: version 4, cipher 3, s2k 3, hash 10
    salt 640c284b119eb28c, count 102400 (105)
gpg: CAST5 encrypted data
:encrypted data packet:
    length: 183
gpg: encrypted with 1 passphrase
:compressed packet: algo=1
:literal data packet:
    mode b (62), created 1445875407, name="x.tar",
    raw data: unknown length
gpg: WARNING: message was not integrity protected

x.tar is the file you would also get as result when decrypting the file manually.


How do you handle untrusted software installation / runtime?

Wrapping the application as a UWP provides some measure of sandboxing but it isn't designed for security so I don't recommend it here.

Personally, I would run such code either in a full VM (e.g. Hyper-V) or using Docker for Windows which would allow some measure of isolation.


Would SSH MitM attacks utilize spoof IPs?

The evidence you've got doesn't point to a MITM attack I'd say.  With a MITM attack the traffic would typically appear to come from the correct IP address, rather than another one.  Another point worth noting is that MITM'ing an SSH connection would likely cause warnings on the client as the fingerprint of the server would be different.

This looks more like a failure in Access Control.  If the access control is intended to be implemented by the SSH daemon (i.e. it is set to only log people in from specific IP addresses) then it's failing to do so by accepting a connection from another address.

If the restriction is implemented elsewhere (e.g a firewall device) then it looks like a possible misconfiguration in that service.


Security is a complex topic. It involves being able to understand complex systems, work with people, and solve problems with technical, social, and business solutions.

For books, I liked "CISSP All-in-One Exam Guide" by by Shon Harris. It covers the basic theory of security and many sub topics. A great history of IT Security theory can be gleaned by reading Early Computer Security Papers.

I would prefer security experts to know a broad range of relevent topics, because failure to understand a relevent domain can lead to subtle vulnerabilities. However, I was taken to task by Graham Lee, who pointed out diminishing relevance in my list of topics.

First off the three essential components of security are availability, integrity, and confidentiality. Others would add in authenticity and non-repudiation, but I would focus on the first three for someone who is just getting started.

Web security covers all the components, actors, and processes involved in web applications. The major components are the web server, the web browser, and the network connecting web browsers to web servers. The major actors are the web browser user, the web site administrator, the network administrator, and the web application creator. Note that there are typically many people filling a specific role, and there are many more roles.

I'm trying to keep specifics short, so I won't include everything. Specifics are as of this posting (mid-2011).

Web browsers

the web browser application: popularity, features, vulnerrabilities, etc

Specifics: Internet Explorer, Firefox, Chrome

user's operating system (what the browse application runs on)

Specifics: Windows XP, Windows Vista, Windows 7, Ubuntu Linux, Mint Linux, Fedora Linux

browser layout engines

Specifics: Trident (Internet Explorer), Gecko (Firefox), WebKit (Chrome)

Javascript engines

Specifics: V8 JavaScript engine (Chrome), TraceMonkey (Firefox), Chakra (Internet Explorer 9), Jscript (Internet Explorer 8)

Java virtual machines
Operating system theory: execution environment, process control, memory management, filesystems, IPC
user's network stack: IPv4, IPv6, TCP, UDP, ARP, RARP, DNS, HTTP, HTTPS, FTP, WebDAV
user's network connection: ethernet (IEE 802.3), WiFi (IEE 802.11),
cryptography: symetric key cryptography, public key cryptography, certificates, certificate revocation lists, Certificate Authorities, and hashing.

miscellaneous: black lists, white lists, sandboxing, downloading, password management, caching, and updating.

Network

network hardware: router, switch, bridge, hub, firewall, proxy, Network Attacked Storage (NAS), Wireless Access Point, SIP servers, VPN servers
network protocols: ethernet (IEE 802.3), TCP, UDP, IPv4, IPv6, IPSec, IGMP, WiFi, ARP/RARP, ICMP, IGMP, BGP, RIP, SNMP, SMB, DNS, DHCP, FTP, HTTP, LDAP, MIME, NetBIOS, POP3, RADIUS, SSH, SIP, SMTP, SOAP, WebDAV)
network configuration and architecture

Web server

http servers

Specifics: Apache, Microsoft IIS Windows Web Server, nginx, Google Web Server, lighttpd

operating systems (what the http server runs on)

Specifics: Windows Server 2008, Windows Server 2003, Windows XP Professional, RedHat/CentOS, Ubuntu/Debian, SuSE/openSuSE

programming languages (used to write http servers, operating system, frameworks, etc)

Specifics: C (Apache), C++ (IIS), Java, JavaScript, PHP, C#, Python, Perl

business impacts (usability, updates, changes, software life cycle, user avoidance and circumvention, user education)
databases (relational, objet oriented, architecture, distributed, transactional, SQL, management, security)

Specifics: MySQL, Oracle, Microsoft SQL, PostgreSQL

cryptography (symetric encryption, public key encryption, hashing, random number generation, salts, digital signatures, HMAC, AES modes of operation, initialization vectors, key generation, key distribution, key revocation, certificates)
network (firewall rules, DMZ architecture, proxys, load balancing, Single Sign-On authentication passing)
server management (user accounts, patches, upgrades, logging, log review, Intrusion Detection Systems [IDS])

Communication

In my opinion a good consultant (of any kind) is an effective communicator.

Technical design presentations and reviews
Solution pitches
Business case reviews
Whitepapers
User education presentations

Other nice to have areas:

computer hardware architecture (CPU, RAM, Disk drives, video displays)
peripheral busses (USB, FireWire, RS-232, I^2C, PCI, SATA, SCSI, Bluetooth)
CPU architecture (operating states [protected mode], I/O bus, registers, MMU, TLB, pipelines, and interrupts)
operating systems theory (kernel types [Monolithic, Microkernel], drivers, memory management, file systems, process control, threads, scheduling)
programming language theory (interpreters, compilers, machine language, symbol tables, dynamic libraries, dynamic linking)
executable file formats (ELF, PE, COFF, a.out)
database theory (relational, objet oriented, architecture, distributed, transactional, SQL, management, security)
file systems (fat32, NTFS, ext2, ext3, linux swap)


Is VM per service a reasonable server security model?

Your assumptions are correct. Security by isolation is indeed a good principle to follow.

There is also a whole Operating System which implements this idea on the Desktop: Qubes OS (Which is running on the laptop I'm using to write this).

To get back to your server model, I think one VM per service is a good idea, but it will become resource intensive.

We have been using FreeBSD Jails system for about 8 years here, to replicate exactly what your are talking about: isolating the web server from the database and the mail server and etc.

What we do is that the Jail hosts runs nothing, except the firewall. All services are isolated into jails, based upon their security domain. We treat the host as you would treat Dom0 under Xen.

Since it is not visualization but instead a very much improved chroot like mechanism, it has not the performances impacts of visualization, while adding separation and security. From the inside of a jailed system, it looks like you are running in a virtualized or real environment. The drawback is that you can only run FreeBSD ( I don't mind, but it might not be suitable for you).

I think Docker is similar in its approach, though I only recently started to use it, and it feels more like a development tool than a replacement for a virtual environment.

Though, I think Xen is worth looking at.


Two-Factor Authentication on downloadable client but not website

Authentication isn't an either/or sort of thing.  An application can have various "levels" of authentication, where higher levels unlock more functionality. For example, you can shop for items on Amazon using just a persistent cookie that tells Amazon who you are-- no password required. But if you wish to perform a purchase or edit your credit card information, a password is required.

Games can be similar. You don't need your second factor to post messages on the game's web forum, but maybe you need that second factor to enter the game (e.g. if entering the game allows you to do more, such as give away all of your in-game currency and/or equipment).

While certain web access seems less secure without that second factor, I'll bet you cannot access your recurring payment information on the web without entering the 2FA info.  This allows the user to do low-security tasks without bothering with the token but offers the necessary protections against high-security tasks.


How to simulate man in the middle attack in android emulator?

Google "MITM PROXY", you will find a lot of tools. One example is:

http://mitmproxy.org/

With cell phones, MiTM attacks are multi-route, so you have to sometimes do some pretty technical set up of environments to completely cover all the paths. Remember you have 3g/4g, sms/mms, wireless, NFC, BT/BTLE.

Of course if you are using just the emulator, then you just have the "wireless" or traditional network route and any of those frameworks should work.


What is the argument for the fairly prevalent "No more than n repeating characters" password rule?

This rule does not make much sense. I believe the rationale between this rule is to avoid people padding their short passwords with repetition of a character (which is a pattern, hence identifiable by password crackers) to meet the minimum length, instead of entering different characters to create a more complex password.

E.g. if the user enters Jane1 as a password and the min length is 8, it will be refused. Then the user might just chose Jane1111. With the rule enforced, he'll be forced to choose something like Jane1yxc. However, he might as well choose Jane1234, which is actually more insecure than Jane1111.


I know basically what you're saying, you need to tunnel your session.

try this:

https://github.com/SECFORCE/Tunna

It's designed to tunnel an installed meterpreter session, through a website. All you have to do is connect to the website with the tunna module.

Let me know if that is what you are looking for.


Security onion only Seeing broadcast traffic and its own traffic

How are these all connected? If you're using a switch, this is to be expected.

On a switch you'll only see traffic destined for your own segment.

Typically for messing around with Security Onion in a home environment, you're better suited replaying some of the included pcaps to simulate traffic since not everybody has a switch with a SPAN port or a bunch of taps laying around.


Does Chrome's password manager store plaintext passwords in their databases?

If you can see a password (in plain text), it cannot have been hashed. The definition of hashing is that this process is irreversible. An alternative, less secure way, to store passwords is to encrypt them. The problem is that you can decrypt passwords, but depending on your use case, this could be a feature and not a bug.

How Google Chrome saves your passwords depends on whether you want to store and use them across devices. When synchronization is turned on for passwords in Google Chrome, your passwords are saved to your Google Account. Otherwise, your passwords are only stored on Google Chrome on your computer.

Not hashing passwords is not a best security practice, but depending on your use case encryption could be acceptable in combination with other security measurements to prevent unauthorized access.

Learn more about storing passwords on Google Chrome on this page.


Is there a need to define "language safety"?

A language can be said to be "safe" if it is possible to implement its interpreter/compiler/runtime environment efficiently, in full respect of the language specification, and still forcibly preventing "bad things" to happen. Then it depends on what "bad things" you are talking about.

Java is "safe" if you want to protect the machine from the code written by the developer. Array bounds are checked, types are unescapable, and memory deallocation is handled by a garbage collector, which means that it is not theoretically feasible to make a Java applet, however poorly written, execute attacker-chosen native code. In the same conditions, C is "unsafe" because it cannot be fully implemented with checks which prevent arbitrary code execution.

Of course, in practice, things change a bit: C code can be made "safer" with various techniques (like DEP and ASLR) and the OS can "contain" native code under some specific access rights (a "normal user" process is not root). And Java actuality shows us that while Java is theoretically safe, the implementation of the Java Virtual Machine and its runtime environment can have holes. To some extent, the exact JVM specification ensures that implementing Java safely is hard (that's a misfeature of the Applet model: it forces per-method control throughout the whole standard library).

You cannot have a one-size-fits-all definition of language safety, unless you are content with a subjective slogan (COBOL sucks ! F# rules ! Prolog forever !). It all depends on the context.


What is considered a reasonably high iteration count?

Well, you said it. The right count is exactly the count which "does not cause the server to slow down to a crawl". You want it to be as high as can be tolerated, given the hardware you use yourself and the expected average load. As @Jeff said, this is a matter of a benchmark.

The whole concept is about making the password hashing process slow for the attacker. This makes it slow for _everybody, including you, so you cannot make it as you would wish. The principle at work here is that your notion of cost, and that of the attacker, are not exactly proportional: a 1000x cost increase is "free" for you if it means that you will spend 1ms instead of 1µs to authenticate a user, whereas turning a 1-hour attack into a 6-week attack is certainly not free for the attacker.


Serverless Apps Authenticate Users After Page Load - Flaw?

The page itself will generally be HTML, javascript and CSS, which are all statically stored in an S3 bucket. Hence the user could figure out what features are available on the page without ever logging in by inspecting the contents of the files -- but they would not be able to execute that functionality, as each API endpoint would be protected to ensure only authorized users could perform actions.

So you might figure out that there is a POST message to be sent to /api/v1/order for making an order -- but you wouldn't be able to successfully make the order without an access token with the corresponding authority.

By downloading the entire javascript, all GUI elements get executed client side, and generally feel snappy -- however this doesn't reduce the security of the overall application.


Secure HTTP login in an embedded (IoT) system

Without proper encryption, an attacker can not only read requests and responses, but also modify them. This means that the attacker can modify the Login.html page to do no encryption at all.
The behaviour of the actual server is no longer relevant, as the client is talking to the attacker and not to the actual server.


To answer the first two bullet points:

Firefox has its own list of trusted CAs. You can add certificates in Menu Button>Options>Advanced>Certificates(tab)>View Certificates>Authorities(tab).
This is for Firefox version 38.
Yes Google is trying to shame people into moving from SHA1 to a more secure hash such as SHA2. Here is the chromium blog post about it. Also see the note at the bottom about SHA1 in root certs being treated differently than SHA1 in intermediate certs.

edit: I came across some official Microsoft documentation for using SHA-2 on subordinate CAs so I will include it in my answer.

  Configuring Subordinate CAs for SHA-2

  The hash chosen on the root CA determines how the Subordinate CA's certificate is signed, regardless of the CSP/KSP and hash is chosen during the subordinate CA's install (and requested in the subordinate CA's certificate request). The requested hash in the certificate request will be ignored and the values in the registry on the parent CA will prevail.

  During the Subordinate CA install, the hash algorithm you select under the Select the hash algorithm for signing certificates used by this CA determines how the certificates and CRLs issued by the Subordinate CA are signed. These values can also be changed using the registry keys indicated above and will apply after a restart of ADCS.

  To summarize, by default, the hash algorithm selected during a root CA's install will determine the hash used to sign the root CA's own certificate and all certificates and CRLs that it issues (although you can change the signing algorithm using the registry changes after the root CA certificate is generated). Subordinate CA's own certificate will be signed by the hash indicated during the root CA's install. The certificates issued by the Subordinate CA will be signed by the hash selected during the Subordinate CA's install. All selected ciphers used for signing issue certificates and CRLs can be changed in the registry, and after restarting ADCS, will apply to all future issued certificates and CRLs.

  It's also important to note that the certificate template version or the client requesting the certificate has no impact on whether or not the CA signs with a particular hash. The hash used to sign digital certificates is determined by the fields and values listed above.


PCI scan reports Apache XSS vulnerability - is it a false positive?

1.

<div class="info-heading">
{IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html (port 80)
</div>

With this particular payload it's a false positive. However, your query already contains HTML entites as input which was probably not intentional:

 GET {IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html

Can you confirm the output is still encoded correctly when you try unescaped input instead? Like this:

GET {IP ADDRESS}/"><script>alert(document.domain)</script>.html

2.

var gCategoryID="';func(document.cookie);'"

With the given payload, this also looks like a false positive, because single quotes don't interfere with the boundaries of a double-quoted string. However, if an attacker could insert double quotes or close the surrounding script tag instead, you'd be vulnerable.

So you need to ensure something like this is also escaped correctly:

https://{IP ADDRESS}/category/";alert(document.cookie);"

If it's not, you can use json_encode() in PHP to prepare a string for safe output as a JS string, e.g.:

var gCategoryID = <?php echo json_encode($category_id, JSON_HEX_QUOT|JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS); ?>


CSRF tokens have two parts - one part is generally set as a part of the hidden form fields, which aren't that hard to find.

Phrased differently, CSRF tokens are stored both client-side and server-side.  Anything stored client-side, you have to assume could be found/read/extracted.  (Assume it can be compromised.)

So it's it's impossible to ensure no one will know what their UID is.  This is why it  should change frequently (as close to "on each request" as possible).

Related: https://stackoverflow.com/questions/1805838/csrf-token-generation

Good resource: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

You didn't mention your platform.  (.NET, Java, PHP, etc).  Many platforms have well-defined libraries for dealing with this.  I'd strongly recommend using one of those if possible.


Please explain the vulnerability for the pre-shared Key for IKEv1 brute force IPSec

A nearly 54-bit keyspace is not even close to enough. Consider that DES, which has an effective key size of 56 bits, is four times larger than this, yet there are numerous services that routinely crack arbitrary DES keys. Even if you changed the PSK once per week, the keyspace is just too low for it to be an effective security measure. You absolutely need to remedy this situation either by allowing for a larger PSK, or switching to an alternative protocol which is suitable for your needs. The absolute minimum key size should be 80 bits, with an ideal key being at least 128 bits.


Why would one show mostly filtered ports and the other mostly closed
  ports and which would be the worse case of the two?

Assuming that you are describing a TCP (full or SYN) scan, then the difference has to do with the way the different hosts deal with unwanted packets.  Closed vs. Filtered does not represent much difference in security terms; in both cases, traffic is not permitted.  It's how it's not permitted that makes the difference.

A quick primer - to set up a TCP connection, the Client and Server exchange three packets, the so-called "TCP 3-way Handshake":

Client -> Server: SYN       ("Can you hear me?")
Server -> Client: SYN/ACK   ("Yes, I can hear you.  Can you hear me?")
Client -> Server: ACK       ("Yes!  Let's get talkin'!")

Nmap uses this exchange in two basic ways:

In an nmap SYN scan (-sS), nmap sends a SYN and waits for a SYN/ACK back.  If it gets one, instead of sending ACK it sends a RST to reset the connection instead of sending an ACK to finish nailing it up.  This has the advantage that the scan only touches the OS, not the application level; since the OS won't tell applications about a connection until it's up and running, the applications won't be logging the connections made by the scanner.

In an nmap TCP scan (-sT), nmap sends a SYN, waits for a SYN/ACK, and then sends an ACK to finish the connection.  This is a "surer" scan in that it proves full connectivity is possible, but it is noisier in the logs.

The thing in common, here, is that nmap waits for the SYN/ACK to determine if the port is open.  But there are three possible "responses", depending on how the target is configured:

Server -> Client: SYN/ACK   ("Port is open, application is listening")

or

Server -> Client: RST       ("Port is closed, server told the client so")

or

Server -> Client: (nothing) ("Port doesn't seem to respond, but not sure why")

Now, the latter two states represent different firewall configurations.  A firewall that is configured to block traffic will respond with a RST, giving nmap a clear signal that the port is unavailable.  On the other hand, a firewall that is configured to silently drop traffic will not respond at all.  Nmap draws a negative inference here and assumes access to the port is being filtered by a firewall.

And that's why you see closed on one system and filtered on the other.  In the first case, the host or firewall is returning RST in order to block unwanted packets, which gives nmap an unequivocal signal that the port is closed.  In the other, the firewall is silently dropping packets rather than noisily rejecting them, and nmap can only infer that the ports are closed.

In Security terms, there's no real difference.  In both cases your packets are not reaching the server.  In some cases an attacker can make inferences about your security posture and concerns from the way and the places you apply blocking or filtering, but that's a subtle aspect of reconnaissance, and much less important than actually blocking traffic you don't want.

There is one important caution that you need to have when scanning.  If a target is configured to block connections, and send you a RST for each attempt, then scanners may interpret non-response as an open port, rather than a filtered port.  The scanner says "Hmm, 65534 ports responded with a RST, but 1 port did not.  That port must be open!"  But if there's any packet loss - which can happen when scanning over the Internet, or even scanning locally with an aggressive enough (fast packets) scan profile - then that missing RST might be a lost packet rather than any indication of what filtering is or is not in place.  It's good practice to verify open ports manually after the scan, especially if you see open ports that don't make any sense (e.g., very high ports).

  When I scan the other computer(B) with nmap from computer(A) it shows
  999 ports filtered and one closed port.

Understanding how scans work - as above - may allow us to interpret their results more clearly.  What I would infer from these results is that 999 ports are being silently dropped by the firewall, but that one port is being permitted through to the computer(B) by the firewall, and that that port is actually closed (not listening) on the host.  So where the firewall is configured to silently drop, the actual host will respond with a RST like it's supposed to.


Would allowing shorter passwords sometimes be more secure?

One related question that you missed in your list is this one:

How critical is it to keep your password length secret?

The accepted answer there (disclaimer: mine) shows that if you have a password scheme which allows all 95 printable ascii characters, then the key space ramps insanely quickly every time you increase the length of the password by 1. You can check all the passwords up to length N in about 1% of the time that it'll take you to check only passwords of length N+1. By rejecting any password shorter than some cutoff length, you give up far less than 1% of your key space.

So, I strongly second @Iszi in saying

  The benefit gained by forcing increased length far outweighs the number of possible passwords lost.

Next point: let's get out of the idea that 8-characters is long for a password. It is not. You say "~13 quadrillion passwords" as if that's a big number. It is not. According to this article (which is a great read btw) his password cracking rig could make 350 billion guesses per second, so every single one of your ~13 quadrillion passwords can cracked one-by-one in ~10 hours. And that's on 2013 hardware, GPUs have come up a lot in power since then.

My opinion is that websites can squabble about who has the better password requirements, but they are all far too weak. Our ability to crack passwords is growing WAY faster than our ability to remember longer ones. This is because security is clashing with usability. Try telling anybody who's not a tech nerd that they need to memorize a 32-character password that doesn't contain any English words, and a different one for each account they have! You'll be laughed at and then ignored. Websites that try to enforce anything better than pathetic password policies have to deal with mountains of angry customers.

The solution is to do away with passwords all together and move towards strong 2-Factor type authentication, where offline cracking isn't feasible. Unfortunately companies have only been seriously thinking about alternatives to passwords for less than a decade and the offerings are far from polished (they are plagued with convenience and usability problems which are preventing mass adoption), so in the meantime we get to continue having these useless debates comparing one mostly useless password scheme against another. End opinion.


The man page doesn't tell you, but if you look at the code the logic for the distinguished_name (subject) section and the attributes section are actually commingled. When you use prompt=no in the config file it affects both of them, and when you use -subj on the command line it uses a different code path that skips, and thus effectively disables, attributes.

Barring a fairly major reorganization of the code, if you want attributes you can't use -subj. You can use the default where you are prompted for both DN and attributes values, or set prompt=no with both values in the config file. If you don't want to actually edit the config file (or versions of it), remember in some Unix shells (including CentOS) you can use process substitution like:

 openssl req -new -config <(cat fixedpart; printf '%s\n' '[req_DN]' 'commonName=test.invalid' '[req_attributes]' 'challengePassword=letmein') ...


The best citation I can give is from Overwriting Hard Drive Data: The Great Wiping Controversy, which was published as part of the 4th International Conference on Information Systems Security, ICISS 2008. You can view the full text of the paper by viewing the book on Google Books, and jumping to page 243.
The following excerpt is from their conclusion:

The purpose of this paper was a categorical settlement to the controversy surrounding the misconceptions involving the belief that data can be recovered following a wipe procedure. This study has demonstrated that correctly wiped data cannot reasonably retrieved even if it of a small size or found only over small parts of the hard drive. Not even with the use of a MFM or other known methods. The belief that a tool can be developed to retrieve gigabytes or terabytes of data of information from a wiped drive is in error.
Although there is a good chance of recovery for any individual bit from a drive, the chance of recovery of any amount of data from a drive using an electron microscope are negligible. Even speculating on the possible recovery of an old drive, there is no likelihood that any data would be recoverable from the drive. The forensic recovery of data using electron microscopy is infeasible. This was true both on old drives and has become more difficult over tine. Further, there is a need for the data to have been written and then wiped on a raw unused drive for there to be any hopy of any level of recovery even at the bit level, which does not reflect real situations. It is unlikely that a recovered drive will have not been used for a period of time and the interaction of defragmentation, file copies and general use that overwrites data areas negates any chance of data recovery. The fallacy that data can be forensically recovered using an electron microscope or related means needs to be put to rest.

NIST also seem to agree. In NIST SP 800-88, they state the following:

Studies have shown that most of today’s media can be effectively cleared by one overwrite.
Purging information is a media sanitization process that protects the confidentiality of information against a laboratory attack. For some media, clearing media would not suffice for purging. However, for ATA disk drives manufactured after 2001 (over 15 GB) the terms clearing and purging have converged.

As such, I'd say that data remanence on modern hard drives is a complete myth, and it's likely to be infeasible for old drives too.
So, as a quick set of bullet points:

You might be able to extract individual bits after a single overwrite, but not any useful amount of data.
It is entirely infeasible to recover any data, even at the bit level, from a wiped disk area outside lab conditions, due to the effects of day-to-day use (file copies, etc).
A single overwrite, for all intents and purposes, provides complete protection against useful data recovery.


SSL does protect the actual files being accessed.  It actually occurs at the IP level, but the main part of the URL leaks via DNS.  This is why you can only have one SSL cert per IP address, because until the connection is established, the server has no idea what is being requested unless SNI is used (which still just provides host name during the connection being established).


Does TrustManager PKIX (or RFC 3280/X.509) really check the expiration date of a client's certificate?

No it doesn't and no it isn't a bug.  For what it's worth, I see nothing explicit in RFC 3280 mandating that path validation fail on expired certificates.

If you have a certificate in the trust store javax.net.ssl default TrustManagers will trust it regardless of expiry.

There is nothing in the JavaDoc suggesting that it checks expiry.  I'd say it's by design.

I dove pretty deeply into the JCL source and it makes no attempt to check certificate expiry.

Other users have encountered and verified this behavior:
https://stackoverflow.com/a/5206923/154527

You will need your own TrustManager to enforce this.


How to encrypt a password stored in a database (need to decrypt later)

You are correct if the system you are connecting to can accept nothing but a password as a credential. If this is how the remote system works, it is unfortunately designed, and should be extended if possible to accept some other kind of token. Examples of more appropriate tokens are Kerberos tickets, SSH keys, OpenID credentials, or other custom per-application credentials.

All of the good authentication solutions have something in common: They allow the user to authorize you to connect on their behalf, without having to give you their credentials. A good system allows my administrative assistant to buy airplane tickets on my behalf. It doesn't require my admin to impersonate me.

If however, the remote systems are poorly designed and cannot accept this kind of delegated credential, then you have no choice but to store the passwords. It is traditional in that case to obfuscate the password in your database using some kind of "encryption key and algorithm." (For example, AES encrypting the passwords against a key stored on disk.) This should not be confused with real encryption; it is only obfuscation. But it can be useful obfuscation if you have no other choices.

A better solution than a single password stored on disk is a hardware key that performs the decryption for you. Such a device is often called a Hardware Security Module and often takes the form of a smartcard (sometimes it's a full rack-mounted device, a board, or a USB key). You present the encrypted password to the HSM, and it hands you back the unencrypted password. The advantage of this approach is that if someone clones your disk, they still cannot decrypt the passwords. HSMs are difficult to physically clone, making it much harder for an attacker to steal the credentials without being detected. In the best designs, the process that talks to the HSM has a credential that is hand-entered at boot and is only stored in memory. So random processes cannot query the HSM, and if the machine is unplugged it can no longer access the passwords. Even in this scenario, it is possible that the attacker might trick the system into decrypting all the passwords for him, but the attack surface is greatly diminished.


Security measures and anti-virus on server to mitigate acting as a propagation vector

By itself, Clamav is not on par with the best commercial alternatives. For best results use multiple detection engines well rated in comparative reviews. Engines with the highest detection rate generally suffer from more false positives, so consider quarantining inconsistent results for later manual checks.
Also available are automated sandbox analysis tools like cuckoo sandbox and online third party services like virustotal's API (the latest only for public documents, although other services may come with an NDA).

File types and extensions should be filtered on a white-list basis. Server-side languages often include a file recognition library which you can use in addition or as an alternative to file -i.
Users should not be allowed to upload encrypted documents or ZIP files whose contents cannot be scanned.

Responsibility and accountability would help users thinking twice before being silly or careless. Ask them to report infections immediately. Keep track of those uploading malware, as they are more likely to do it again. Website usage patterns may reveal leaked credentials and malicious behaviour.

The single most effective mitigation towards overall security may be an awareness web page for users prepared in coordination with the appointed company department. This would prevent infections of user machines in the first place. Mind it is not a technical measure, it is outside your scope and it may minimize the perceived value of your other efforts.


I haven't seen much in the way of guidance on this, but from what I can see you're not likely to run into any issues.

Theoretically, you'll be reducing the entropy of the input if your inputs are larger than your first hash. In reality, I'm not sure that it's a problem.

When migrating an application from unsalted MD5 to bcrypt, I simply bcrypted everybodys MD5 hashes then bcrypt(md5('password')) to check it at login. I reasoned that MD5 digests are 128-bit and that's much larger than than the likely entropy of peoples passwords.

In comparison, whirlpool hashes have a digest output of 512-bits.


Very easy.

Didier Stevens has provided two open-source, Python-based scripts to perform PDF malware analysis. There are a few others that I will also highlight.

The primary ones you want to run first are PDFiD (available another with Didier's other PDF Tools) and Pyew.

Here is an article on how to run pdfid.py and see the expected results; Here is another for pyew.

Finally, after identifying possible JS, Javascript, AA, OpenAction, and AcroForms -- you will want to dump those objects, filter the Javascript, and produce a raw output. This is possible with pdf-parser.py.

Additionally, Brandon Dixon maintains some extremely elite blog posts on his research with PDF malware, including a post about scoring PDFs based on malicious filters just like you describe.

I, personally, run all of these tools!


If your objective is to find vulnerabilities, I would say Nessus is enough. It's primarily a vulnerability scanner, which can of course do "normal port scanning".

Nmap's main focus is more about detection and auditing, although it's possible to detect vulnerabilities with the scripting engine. I suppose Nmap might be more accurate to determine versions, or minor things like that, since there is a lot more options for scanning and detection, but as long as Nessus finds the same open ports, it shouldn't matter.

Here is info about The Nessus Port Scanning Engine: An Inside Look, and well, Nmap Port Scanning Techniques begins at that page.


When I reset my password for my Microsoft account, how do they know what password I've used before?

They know the value to which your previous password(s) hashed, and the salts used. When you type your old password, they compare it to the old stored passwords.


In what sense is Knock to Unlock safer than a password?

It depends on how they implement it, but the most secure would be to use that with a password.  They are probably using a certificate based system which wouldn't be able to be guessed and they are turning the phone in to a "what you have" token that can pass the information to the authentication system when you prove you have it by knocking on it.

The exact security of the system would depend on how secure they implemented the authentication though and unless it requires a password to be entered on your phone, it reduces security related to someone being able to simply rob you for your phone to get in to your computer even though it would increase the security of someone without access to your phone being able to get in.

This is why two factor authentication is typically considered a best practice, that way they need not only something you have but also either something you are or something you know.  Generally, it's also good to have at least one be something you know since it's far easier to force you to use your biometrics or take something from you, but they can't force a secret out of your head, but some cases are ok to be who you are and what you have.


How does SSL implement server authentication?

The client compares the server hostname you type into the URL against the subject name in the certificate. If they match, then it's the right server. If they don't match, then it's the wrong server. That simple.

See: How does SSL/TLS work?


Use the PROXIES environment variable (while in msfconsole) :
set PROXIES HTTP:127.0.0.1:8080

Or run Metalsploit with proxychains (config at /etc/proxychains.conf) http://proxychains.sourceforge.net
Notice that using burp is not helpful to inspect protocols other than http.


Can employer retrieve file emailed over https from months previous?

Yes, it could be possible for them to retrieve the contents of the email. There are two options:

They monitor the network, i.e. do MITM and TLS-intercept. The fact that you didn't find your company name in the certificate chain is no guarantee that there were no rouge certificates installed in your trust store. They could be named something much more innocent.
They monitor your computer, e.g. by saving files opened by browsers as suggested by Matthew.


I believe the PayPal Vault just stores the card token. So if an attacker were to grab that token and some other sensitive information from your server, the worst he would be able to do is charge the person's account to your PayPal account, approve refunds, etc. The customer's actual details will stay private as they are not transported from the vault.

The way I see this working is in this wise:

Customer ---card number---> Your server ---card number---> PayPal Vault

Once in the vault PayPal generates an ID for the card and sends that back to you:

PayPal ---card id---> Your server ---card id---> Database

So later, when you want to use it again:

Database ---card id---> Your server ---card id---> PayPal Vault

PayPal then matches the ID to the card number stored in the vault and charges the card.


Can you have Secure encryption with a backdoor, and still be secure?

To your first question, no, the backdoor is a flaw in the encryption.  Think about Kerchkoff's Principle: a system must remain secure, even if everything about the system is known except the key.  A backdoor would be revealed by examination of the system.

However your second clarification is talking about the concept of key escrow.  I may have my secret key, but the company also has a secret key.  Either one can decrypt the message.  Those are common, and supported in various security packages.


Truecrypt hidden partition deleted original drive data

@gowenfawr seems to be correct here, but let me try to clarify exactly what's happened.

First, some quotes from TrueCrypt's own documentation on Hidden Volumes:

  The password for the hidden volume must be substantially different from the password for the outer volume.

and

  TrueCrypt first attempts to decrypt the standard volume header using the entered password. If it fails, it loads the area of the volume where a hidden volume header can be stored

Now, here's what (I believe) happened in your case, step-by-step:

You created, formatted, and stored data on a TrueCrypt volume, which for the sake of this walk-through we'll call "OuterVolume".  Also, for the sake of this walk-through, we'll say you used (please, don't ever) "Password1" as the password.  And, let's say you decided to store this within a file called "MyVolume.tc".
Then, you attempted to create and format a Hidden Volume which, for the sake of this walk-through, we'll call "HiddenVolume".  You created HiddenVolume within OuterVolume and used "Password1" as the password.

Here's where things got borked.  When TrueCrypt went to open HiddenVolume to format it, this is what (I believe) happened.  This may have been step-by-step as you executed it, or some of it may have just happened in the background:

When attempting to open HiddenVolume for its initial formatting, you pointed TrueCrypt at MyVolume.tc and gave it the password of Password1.
TrueCrypt attempted to decrypt the first volume header (which would be the one for OuterVolume) with the given password.
Since Password1 is also valid for OuterVolume at this point, the header decryption was successful and TrueCrypt stopped looking for other headers.  It then used the key to finish decryption of OuterVolume.
With OuterVolume having been mounted, but you believing it was HiddenVolume, OuterVolume was then formatted and HiddenVolume was left untouched.

Now, to explain what's happening after the password change:

For the sake of this walkthrough, you changed the password to OuterVolume, to "Password2".
You attempted to mount MyVolume.tc with Password2, and succesfully opened OuterVolume.  Now you see that OuterVolume was formatted earlier, when you thought you were formatting HiddenVolume.
Then, you attempt to mount MyVolume.tc with Password1.  Since TrueCrypt can no longer decrypt the first header (for OuterVolume) with this password, it now moves to look for the space where a Hidden Volume's header might be.
TrueCrypt successfully decrypts HiddenVolume with Password1, and now you see an unformatted volume because, after all, HiddenVolume was never itself formatted.

It should be clear by now, that all of the data previously stored in OuterVolume is more than likely lost forever.  I know of no software (though it's imaginable, I doubt it exists or is within the realm of common affordability) that can perform any sort of undelete on an encrypted volume, let alone one which has been re-keyed.  If you would still like to work with HiddenVolume without nuking MyVolume.tc entirely, you just need to make sure that the keys for OuterVolume and HiddenVolume are significantly different and then reformat HiddenVolume.  Additionally, TrueCrypt recommends:

  To the outer volume, (before creating the hidden volume within it) you should copy some sensitive-looking files that you actually do NOT want to hide.


SHA256 is still a secure hash.  As a result the main concern is someone trying to bruteforce your access token.  SHA256 isn't a slow hash so depending on how much entropy your access token has, this may be a valid concern.  You can calculate the cracking time from the amount of entropy versus the hashing rate the attacker can achieve.  As it turns out, SHA256 is what bitcoin uses so hashing rates for various setups are readily available.  For non-specialized GPU hardware you can roughly estimate a hash rate of 1GH/s (1,000,000,000 guesses per second).  Let's take that and run through two extreme examples of the entropy of your access token:
1. Access token is a simple permutation of creation time + user id.
Ever seen something like access_token = md5(time() + $user->id)?  Things like this are surprisingly common.  If an attacker knows the id of the user they are trying to attack (which is likely since it may also live in the logs) and know how your access tokens are created, then they just need to guess the account creation time.  Even if the creation time includes microseconds, this is still extremely easy to guess.  At a rate of 1GH/s and given a fixed user id, you could brute force all creation times over a decade in a second ((86,400,000 possible hashes/year) * (10 years) / (1,000,000,000 hashes/second) = ~1 second
This access token has no security from brute force at all.
2. Access token is a GUID
Alternatively, your access token may be a GUID.  These typically have 128 bits of entropy or roughly 3.4e38 possible combinations.  This means that bruteforcing one would take: 3.4e38/1e9 = 3.4e29 seconds, which is approximately 10,000,000 times the age of the universe.
This is absolutely safe from brute force.
Another option
Finally as a different suggestion (which may not be applicable) is to store the id of the access token, presuming that it is stored in the database and therefore has an associated id.  After all, the access token is the sensitive part, but the id of the access token is just as useful for tracking and (normally) not sensitive.  Of course if you aren't storing your access token in a database (for instance, if you are using a JWT) this isn't possible.


Browsers don't directly make a listing of the installed fonts available. Instead they provide information about the size a specific object like a textbox has. Since the same text rendered with different fonts causes slightly different object sizes this can be used to infer which font was used to render a specific text and thus check if a specific font was used to render the text (and is thus installed on the system) or not.

For more information see Font Fingerprinting at browserleaks.com or the paper Fingerprinting web users through font metrics.


openssl serial number error "SEC_ERROR_REUSED_ISSUER_AND_SERIAL"

How does my browser know this?

Firefox seems to cache information about certificates which got used, at least until you restart the browser. If you've added an exception because you are using your own (maybe untrusted) CA then it might even have the information in the CA store.

  What security risk would be entailed if my browser just ignored the duplicate serial number?

Revocation information about a certificate issued by a specific CA are checked by serial number only in CRL and OCSP. Thus reusing the same serial number would mean that the same revocation information get applied.


Is it possible to exploit unescaped user input into JavaScript form which only gets data via AJAX request?

There's not enough information provided to correctly diagnose whether this is a vulnerability or not.

If it was possible to trick a user into making the request directly to /data and include the malicious payload (<script>alert(1)</script>), then yes it would be a vulnerability if the alert box appeared.

For example by tricking the user into visiting the attacker's site which contains a redirect to https://example.com/data?<script>alert(1)</script>
or contains a form that POSTs to https://example.com/data with the request body set to
data=<script>alert(1)</script>.

This would hinge on whether /dataresponds to none-AJAX requests also. Additionally, the content type returned would need to be text/html for any script to be rendered and executed by the browser.

Also, your payload might only be rendered with a form encoding type of application/json. If the /data handler only responds to requests with this encoding type then it is impossible to make these requests with a <form> tag.

If it is still renders the response with a different content-type specified, then you may be able to get it to render by "tricking it" with a text/plain form:

<form enctype="text/plain" method="post">

  <input type="hidden" name="{&quot;data&quot;: &quot;<script>alert(123)</script>&quot; }//" value="" />

  <input type="submit" />

</form>

The other avenue to explore is whether you can get /some/page to pre-populate the textbox with your payload. Try common parameters such as:

https://example.com/some/page?data=<script>alert(123)</script>
https://example.com/some/page?value=<script>alert(123)</script>
https://example.com/some/page?<script>alert(123)</script>
https://example.com/some/page?debug=<script>alert(123)</script>
https://example.com/some/page?test=<script>alert(123)</script>
https://example.com/some/page?id=<script>alert(123)</script>
https://example.com/some/page?etc=<script>alert(123)</script>

Have a look what you've observed on the rest of the site (e.g. check Burp's sitemap) and make a list of commonly used parameter names.

See here for my answer to a similar question.

If you cannot check these things yourself then you would need somebody with web security skills to verify whether this is a vulnerability or not. If it is not possible to hire somebody, then you would be best hedging your bets and fixing it anyway.


Surveillance: blocking laptop's microphone from spying on you?

This issue affect both laptops, tablets and cellphones with similar solutions, so even if only laptops were explicitly mentioned in the OP's question (with still a link to an article focusing on cellphones), I think it can be useful to address the issue as a whole.

There are several ways to counter malicious use of embedded microphones:

Physical destruction / removal of the microphone,
Using a dummy plug,
Relying on software isolation techniques,
Using specific hardware to mitigate privacy issues.

Let's see each one of them, what they are all about, and what are their strengths and weaknesses.

Physical destruction / removal

The most well-known and most effective solution is to physically destruct (drill) or remove (desolder) the microphone: no microphone anymore, no malicious way to use it. An external microphone can then be plugged whenever required (earphones for instance in the case of cellphones).

Be aware however that certain devices (in particular cellphones and tablets) may contain several microphones working together (mainly used to attenuate background noise): you must be sure to not miss any of them.

The iFixit website is usually a great place to find teardown videos, unmounting instructions and even vendor specific tools and parts for various hardware including cellphones and computing devices.

But apart from the actual microphone(s), researchers have found that mobile devices gyroscopes (which do not even require any authorization in the case of mobile apps) can also be used as low quality microphones. So, the "no microphone, no audio spying possible" adage may not be completely true.

Using a dummy plug

As recommended  at the end of this article, this is most probably the easiest way to get an easily reversible deactivation of the microphone. All you have to do is simply cut the plug from some old microphone or earphone and put it into your device to disable the main microphone, just unplug it and the microphone will be back.

However, do not assume that while this requires a physical action on your side this means that the microphone will be physically disconnected. I remember old issues when running Linux on some laptops where plugin in earbuds would not deactivate the laptop's main speakers: sound would be diffused through both the earbuds and the main speakers. This means that some action had to be done at the software level in order to disable the main speaker when an earbud plugged-in event is triggered.

One cannot exclude that the same rule also goes for the microphone. Depending on the device, plugin in a dummy device may indeed physically disconnect the main microphone(s), or the main microphone(s) may still remain reachable at a low level.

Nevertheless, this should still be efficient notably against spyware relying on the device's standard audio stack and against cellphones' hidden automatic callbacks which, IMO, are the most common threats.

Low level attacks are more in the realm of targeted attacks, and if you are a high enough target to justify such investment from the adversary and it turns out that your devices are affected by low level malware (or you assume so by default, which may be wise in such circumstances), then your balance should go more toward drastic measures than convenience and physically removing microphones may seem a minimum.

Software isolation

The most documented entry point for the attackers remains at the software layer, whether by exploiting some flaw or manipulating the user into running malicious code.

Hardened desktop computing platforms (mainly Qubes OS and to a lesser measure the newcomer Subgraph OS in the FOSS realm, Polyxene in the proprietary realm, there may be other) strongly isolate software from the hardware. There is no real equivalent on mobile devices, as their low-consumption CPUs do not offer virtualization feature yet, however there are early ongoing projects integrating LXC into Android which seems to be a very promising first step.

On such systems, in order to reach the microphone a malicious software has to be able to escape the containment system and build a covert channel through it. This provides a good protection level even against targeted attacks.

However, in case of a high value target, chances are that the attacker will just try to bypass the whole operating system at once and directly reach the lowest and most privileged layers by taking advantage of:

The Intel Management Engine (and its AMD equivalent) on computers,
The baseband firmware on cellphones.

As far as I know, there is no real solution to these threats.

For computers: older computers do not come with Intel Management Engine and using libreboot allows to disable it on pre-2009 computers, but there does not seem to be any solution on recent platforms except using specific hardware as discussed in the following section.
For cellphones:

The osmoconBB publishes a free implementation of the GSM stack to replace the opaque default one, but AFAIK there is no other project going any further.
On their Hardening Android for Security and Privacy, the Tor development team launched a call years ago for devices where the baseband hardware would be effectively isolated from the rest of the device but with no real luck.

Using specific hardware

A few projects aim to find solutions in order to provide platforms as trustworthy as possible to their users, allowing to have a real control on the hardware behavior.

For the computers:

The Purism company (clearly a pun on NSA's PRISM project) builds laptops and tablets with a specific focus on privacy (by the way their Librem 13 model is the first officially Qubes-certified laptop). One of their originality is to equip each one of their product with hardware switches allowing to physically disable the camera, microphone, WiFi and Bluetooth. However, they still seem to run on CPUs enforcing Intel Management Engine (an Intel Core i5 in the case of the Librem 13).
Crowdfunded projects like the EOMA98 (also featured in Linux Magazine) try to create the most open platform as possible. This one especially is interesting due to the care taken in choosing the components, most especially the CPU. Such project rely on low-consumption CPUs, which does not provide the same computational power and cannot run a hardened desktop OS like Qubes OS (see the "Software isolation" part above, the limitation are the same as for mobile devices)... for know, since things are moving very quickly in this area and I don't see why open hardware would not follow the same path than open software (being optimistic, I would say that bugging their own CPUs was probably the nicest present Intel and AMD could have made to their competitors).

For the cellphones:

There are comparable projects on cellphones side, like the Open hardware Cellphone which rely on the Adafruit Fona cellular phone module, but as stated above you remain stuck with GSM with no concrete future plan to go beyond this. Moreover, while the hardware itself is open I am not sure at all that this module's firmware is open source (?), in which case it would solve absolutely nothing regarding the network baseband module trust issue. However, such device would still give the opportunity to have a better control on the microphone (and camera whenever you add one), for instance by adding a switch like the one equipping Purism computers.
Mike Perry from the Tor project has written and maintains a guide on Hardening Android for Security and Privacy. In its current shape it is described more as a proof-of-concept due to usability issues, but it still provides a wealth of information. Fundamentally, due to the lack of proper isolation between the network baseband module and the rest of the cellphone, the idea is to use two devices:

A WiFi-only tablet with no cell network support and optionally the microphone removed (this is actually only to address a potential software exploitation now, since the microphone is effectively out of reach of the cellular network),
A separate cell modem device providing WiFi access for data services only,
Use VoIP (or whatever you like, as long it is data) on top of that to communicate.

Conclusion

Practical security is mostly a matter of balance between pure security and convenience. As always, the exact good answer heavily depends on your actual needs and threats you are really facing, but to give an idea:

For high-profile targets (I mean life or death issues, not a teenager downloading some warez ;) ), I would feel more comfortable with a solution relying on specific hardware whenever possible (ie. when such solution, which are still in their infancy, suits your needs), otherwise on physical modification of more common hardware by removing the microphones and putting some black electrical duct-tape on the cameras.
For privacy-conscious users, unless their geeky part push them to actively participate in the open-hardware move, using low-level software isolation on computers, a dummy plug in the cellphone and some black electrical duct-tape on each camera should be sufficient to quickly and easily provide a good level of privacy without really sacrificing convenience.


Is it safe to send an encrypted blob as a URL parameter?

I don't discuss the security of the password link since I see the problem with your approach even before this link is generated. Your first step after some unauthorized user requested a password reset is to:

Set the password to a temporary, randomly generated password

The problem with this approach is, that a reset of the password of a user can simply be requested by anybody. Based on your description the users password then gets immediately  set to some random value, which would immediately deny  access to the real user. The user only gets access back if it follows the sent password reset link or triggers their own password reset.
In the mean time an additional step was added to address my concerns:

If Self-Service via the web - require the user to prove that they are the account owner by making them answer their security question

This does not actually prove that they are the account owner. The actual prove for this would be entering the password, which the user no longer has. Answers to security questions instead tend to be easily solvable for others since they a) tend to be simple and b) tend to contain information which can be found on the internet (i.e. Facebook page of user etc). Also, the attacker only needs to know the answer to the security question once in order to reset the password again and again, meaning an effective DoS to the real user.
Also, there is no actual need to reset the password immediately, since the password itself is not known to an attacker. This kind of procedure was only added to make the link simpler, i.e. for technical but not security reasons. But the link can simply contain a username and expiration, signed together with a server side secret. This way the link functions as a time limited request for password change, authorized by the server. The actual changing of the password should only happen once the link was clicked and a new password set by the user.
For more recommendations on this kind of functionality see How to implement “forgot password” functionality?.