So, in general, your thought process is correct.

Create the digital content Document and save it.
To prove that Author last saved Document they would sign the file with their asymetric key
To prove when Document was saved you would cryptographicly time-stamp it with the help of a trusted Time Stamp Authority.

At any point in the future anybody can validate that the file is the same as it was at a point in time (unchanged since step 3) by validating the timestamp hash with the help of the TSA.

At any point in the future anybody can validate that the file is unmodified from when the Author saved it (unchanged since step 2) by validating Document's signature using Author's public key.

At the core, this seems to be what you are thinking about and yes this is how it does work.  And yes, an implementation along these lines does comply with every standard that I am aware of (I work in the USA, but not with the FDA) for proving authenticity of documents across a time domain; including digital contracts (it provides proof of identity and proof of time signed).  Though if you are attempting to use this for any purpose where compliance is mandatory then you should take the entire matter up with legal council.  Let me be clear: I am not a lawyer and nothing I say should be construed as legal advise or a recommendation on a legally acceptable course of action for you and/or your company.  If that is what is required, make sure that you and/or your company bring in your/their own lawyers to ensure you are compliant.

OK, now that the CYA is out of the way we need to look at implementation.  You have a data payload for which you wish to guarantee authenticity.  This isn't uncommon and is something we all deal with regularly ("verify the file hash before installing", "verify the message signature with my public key", etc).  It is a known solved problem in our world.  For verification of integrity of the payload, a hash of the payload is computed for comparison.  For verification of authorship of a payload, the hash is computed and then cryptographicaly encrypted (using the Author's private key) -- a method we refer to as "signing the document".  While you verify the integrity by making sure the hashes match, you check the authorship by decrypting the "signature block" using the supposed Author's public key -- this gives you the file integrity hash that you then verify as before.

Again, this is a solved problem with various schemes in existence to perform it.  One of the most common is Pretty Good Privacy (PGP).  The PGP standards include a full definition of how to create good cryptographic keys (a required pre-req for signing) and how to properly sign a message.  At this point you get into the discussion of Opaque Signatures (where the signature and payload are combined into a single output) and detached signatures.

With an Opaque Signature you will only have one file in the output.  It is a combination of the data payload from the original file, and the signature block.  While this works well when you are also encrypting the payload (so you'd have to perform a separation and decryption to use the data anyway) its usefulness in scenarios where there is a desire to directly consume the data by an external program varies depending on if that program will be OK with the signature block.  For textual messages an Opaque Sig normally isn't an issue.  For binary files it will all depend on the software you want to use the file with.

Contrast that with a Separate Signature, where a secondary "signature file" is created to live side-by-side with the original (payload.data and payload.data.signature).  This method increases your file count since there are new files for each signature, but the original file will still be able to be opened/viewed in it's intended software without any extra modifications or allowances.  This makes the separate signature the more common method for binary files that remain in use.  Separate Sigs also have an advantage when using a Time Stamping Authority; you only have to time-stamp the .signature file, reducing the size of the file being transmitted to/from the TSA.

And that then brings us around to the TSA's role in all of this.  The thing about a Time Stamp Authority is that they should be near-universally trusted, external and unaffiliated to the parties they provide timestamps for, and impartial in their review of any action.  The TSA's role requires them to be neutral across the domain where they are required to provide actionable data.  That means if you only need a TSA to provide internal audit timestamps but those aren't required externally, then you can run your own internal authority.  But if you need to be able to prove to an outside party that something is accurate as of a given date/time, then the TSA used should be external to both of you (to prove neither of you are tampering with the results).  What the TSA actually does is take a file/data, add a timestamp (and, often, information about who requested the time stamp), and then sign the whole thing.  So in the end, you may have payload.data, payload.data.signature, and payload.data.signature.timestamped (in some cases .signature is superseded by .signature.timestamped as the final file can provide both functions; other places may need to keep both.)

But this brings up the issue on offline time-stamping.  And the answer there is, no.  Using a TSA is, by its very nature, asking an external auditor to verify the time something happened.  Using an offline TSA (I'm reading it here as: "I self-timestamp the documents without using an external party") breaks the entire reason for performing timestamping at all -- having an unbiased external party verify the time.  Otherwise you might as well use the "last modified on date" from the filesystem; you can change your system clock and fake the modified date as easily as you could change the clock and fudge your own internal timestamp.  (again, consult your lawyers, but if you're trying to comply to FDA standards then I'm going to assume you're trying to make proofs to an external regulator of some sort)  So, no, an offline (or an internal, or an affiliated-to-you) TSA would not fulfill its purpose when trying to make proofs to external entities.

And, finally, a thought about something that came up in the comments (and I briefly touched above).  There was some consideration about the fact that this balloons the number of files associated with a project.  And, while the .sig and .time files may be small in size, it certainly does.  One thing to look at if this is a consideration is what kind of files are being verified, how often in their lifecycle a time stamp is needed, and if they are individual & separable or a group of files in a single project.  Most often such signatures and timestamps are applied to final output (or major checkpoint, but not to works in progress); so you don't need tons of these files for points-in-time, just the very few to handle when you need an authority signature.  And, often one will look for this kind of authenticity verification for a project and not individual files.  If that is the case, it may be prudent to bundle the files together in a single container (zip, tar, etc) and then perform the signing and timestamping on that container.  Then you'd have two files: a single archive file for each completed project, and a .signature.timestamp to verify it.


There may not be a justification "security wise", but there are other design considerations which are worth exploring. In my opinion, the biggest advantage of using OAuth is that you abstract the authentication method from the various systems required authentication/authorisation (this is something tylerl was describing).

As an example: you start off with one service which you authenticate against using JSON username/password. Everything's working well, but you decide to introduce another service which provides slightly different functionality. The new service also accepts username and password via JSON.

At some point, somebody points out to you that MD5 is broken, or you're not salting your passwords correctly. No problem - you can fix that. But you have to fix it in both (all) of your services which are performing authentication... How many of those do you have? Do you actually know where they all are? How can you deploy the change to all of the services at the same time?

By performing authentication against an Authorization Server, as in OAuth 2.0, you partially remove this dependency. You can easily change the authentication mechanisms within this server, and as long as your services continue to accept OAuth tokens, you have no problems.

The other important point is that OAuth is a standard pattern. When it comes to authentication, adopting standard patterns are always better than implementing your own authentication schemes. Furthermore, if you wanted to expose your services via the Internet at some point, the fact that they accept OAuth access tokens would make the whole process a lot easier.


What is a good symmetric encryption algorithm for many small texts?

It’s not the algorithm you should be concerned about as much as the encryption mode. Sure, you need to use a strong algorithm such as AES, but there are several you could choose from.

What you really need is to use it in a secure mode (not ECB!) with a unique IV. As long as each message has its own IV, it won’t encrypt to the same ciphertext. That way an attacker can’t correlate different encrypted messages to see if they’re the same.

There are no known attacks against related plaintexts in any strong, fully implemented block cipher. (There are some reduced-round attacks against some ciphers, but that’s one reason the algorithms specify more than enough rounds to defend against them.)

EDIT: Lie Ryan raises a good point. Make sure that message length doesn’t betray any secrets. For example, if you have a field such as “VIOLATIONS”, I might infer that a a 16 byte cipher text means “N/A” or “no data”, while a 19K ciphertext might mean the client often violates rules.


Breaching security of a notebook with full disc encryption when screen is locked

Can anyone point out any weakness in this setup, and if you do, how to
  make it secure?

Hardware solutions exist which can grab your system's memory without needing your login.  And that's pretty much the weakness - if someone can get access to your system's memory, those passwords (or, at worst, the keys formerly unlocked by those passwords and still in use) can be captured by your opponent, who will then use them to access your (probably imaged) disk at will.

So it's a question of your risk profile and how paranoid you are.  If you're running the Silk Road, then you shouldn't ever step away from a running laptop (and, quite frankly, after you shut it down you should shake it around and let it cool for a few hours before walking away from it.)  If you're working for Shower Widgets International, you probably don't have so much to worry about.  If you're a grad student... then you need to worry again.


Your explanation is fine! I think I understand your question.

DDoS Mitigation works generally by placing a mitigation device/system upstream from your internet connection.  You can contract a DDoS mitigation service like Prolexic for these services, or you can go with a cloud provider that already includes DDoS mitigation from whatever vendor.

It is impossible to mitigate DDoS at the physical level from your server because the packets are likely flooding the next hop up on the network, e.g. your ISPs local switch.   So, you can be dropping the packets all you want, they are still coming from the ISPs switch to your network and utilizing your bandwidth.  Thus, to mitigate the attack, the packets need to be dropped upstream.

For smaller web sites, you can use a proxy service like CloudFlare -- in fact, this is the preferred solution for many until they reach very large size.  CloudFlare works by controlling your DNS for the domain.  It then proxies all web traffic through its network and servers, which are heavily fortified to withstand DDoS attacks and also to intercept other common hack attempts such as XSS and SQL Injection.  Legitimate traffic is then forwarded to your web server while suspicious traffic is dropped upstream, leaving you unaffected by the affects of a potential DDoS.


Do I need a "cryptographically secure" random value for an unguessable URL?

uniqid might not be the best choice, in part because the docs do mention (in red):

  Warning
  This function does not guarantee uniqueness of return value. Since most systems adjust system clock by NTP or like, system time is changed constantly. Therefore, it is possible that this function does not return unique ID for the process/thread. Use more_entropy to increase likelihood of uniqueness.

And I would tend to suspect that ID collisions would be fairly disastrous in your case.

I think the basic answer is that if you really have a requirement for unguessable, as opposed to simply unique, you probably want to use a cryptographically secure RNG.

Or use a UUID (https://en.wikipedia.org/wiki/Universally_unique_identifier) - there are options, specifically UUIDv5, that would seem better suited to your usecase that uniqid.


Should I get an antivirus for Linux Desktop

AV pros:

Can detect old viruses
Sometimes can detect recent viruses (depending on vendor detection/update time)
Sometimes can proactively detect viruses and alert to a suspicious activity

AV cons:

Do contain bugs (all software does) and run with high privilege level, sometimes exploitable.
Usually consist of megabytes of closed-source, really complex (parsers for tens of file formats, process monitoring, etc...) code that you run as root.
Demand trust in vendor, vendor's internal security architecture, vendor-generated SSL certificate for https web AV functionality, ...
Slow down your system
Do close to nothing against qualified attacker or targeted attack.

I tried to be objective, but my bias is clear. AV can protect against CoolPhoto.jpg.exe email attachments, but if you are advanced enough to run Linux on the desktop then you do not need that protection.


JWT authentication and authorization schema

As @jpodwys says in his comment, HTTPS is a secure transit. It seems very unlikely to me that an attacker could steal an OAuth2 refresh token and not steal other critical information. That is, by the time you are having tokens stolen over HTTPS connections, you've already been pwned and it's game over. OAuth2 is a well-tested protocol that has many tested implementations in many languages. I strongly suspect that it will be more secure than anything that you choose to design and implement on your own. In general, rolling your own is a mistake. See all of these answers for reasons why.

In answer your question about why refresh tokens exist, they exist to allow the user to revoke authorization, not to deal with a stolen refresh token (as that effectively never happens). Consider the case where a user grants access and then later, abruptly revokes it. You want to minimize the delay between the revocation occurring to the revocation having effect. One way to bring the delay to (near) zero is by checking with the service provider on every call. But checking with the SP on every request isn't performant. Instead, you allow the access token to be used for a limited time period and force it to be renewed every once in a while. This means that if the user revokes authorization, it will take effect in a time no-longer than the life of the access token.


Expand user login in Path - Filter malicious values

There is no doubt that the white-list approach remains the best one (actually I would even add a maximum size limitation to this regex, I guess a legitimate login counting several hundreds of characters should not be so frequent...), because it will protect you also against a range of unsuspected exploits and brings you some level of trust that the login passing this tests, whether valid or not, are correctly formed and will not have the possibility to harm the system.

Having user names to comply with some reasonable pattern does not seem an excessive requirement (Have you ever tried an account like "foo' or '1' ='1" somewhere? Or claimed that your really need unicode or non-standard charset support for your favorite login?).


MFA token for authentication to a call center

There are a few common ways to do that:

SMS tokens: send a random password to a registered mobile phone. That's basically the lowest possible standard for 2FA since SMS aren't exactly secret and many smart phones will (by default) display the content of the SMS message without requiring the user to unlock it. Basically, it just verifies that the user can view the phone's screen.
HOTP/TOTP: Defined by two RFCs, 4226 (HOTP) and  6238 (TOTP), these are one-time passwords that are generated by a small software. Google authenticator is a famous implementation of that standard. It's very easy to implement and requires next to nothing in therms of fixed costs. It's a bit better in terms of security than SMS but requires more work from the user. It's therefore used in more technical-oriented environment.
Security tokens (RSA SecureID, Sefenet SafeWord, for instance) are dedicated security devices that will generate single-use or time-based passwords according to a key that is stored in a tamper-proof container. The reason these are safer than software tokens is that the tokens are VERY hard to copy and the secret key is therefore well protected. Deploying these is pretty expensive, though.

There are plenty of other two-factors systems out there for a variety of costs and functionality. These are just a few examples that fits your requirements


....  your connection is not private i proceed to the website ...
  What are the steps to take after adding an invalid certificat authority?

You probably did not add a new certificate authority. If you simply clicked to make an exception in order to proceed you've only added an exception for this specific certificate used on this specific site. This is different from adding a new certificate authority (CA) which would be able to issue certificates for lots of sites. Steps to adding a new CA are more complex then just agreeing to add an exception.

The steps to remove an exception you have added to a browser depend on the browser. Google will help when you ask the right question.

  in the future, how can I proceed to the payment of my bills safely and without using a VPN?

If you get a security warning only for a single specific web site then chances are high that this is caused by a bad certificate on the site itself. Contact the site owners in this case so that they fix it.

But if you get such a warning for most sites then either the time on your computer is way off and thus most certificates are considered not yet valid or already expired. Or there is some SSL interception going on (i.e. man in the middle). This might be legal if you are inside a company and you should contact your local administrator on how to proceed. If you are in some public network then it might be caused by a hacker playing with the customers and you should not proceed. If this happens inside your own network something is very wrong there which you should fix before continuing with sensitive transactions.


First of all, there are different attacker scenarios, lets start with some theoretics:

First, you might be concerned about attackers from the Internet. Here the firewall is a rather important thing. It primary separates local traffic within your LAN from getting into the Internet and prevents unwanted traffic from the Internet entering your LAN.

Especially, if you did not set up remote access, the latter means nobody from the Internet can access your local admin page. While the former means if you send locally your admin credentials to your router, that message never leaves your LAN and therefor can't be sniffed by someone out in the Internet.

Secondly, you might assume that the attacker has direct access to your LAN. Either because you just mistrust your fellow LAN users or because someone from the Internet already hacked one of the devices within your LAN. In this case it might be possible for the attacker to read your password while you transmit it to the router via HTTP. So your indeed should prefer HTTPS.

About your more practical issue:

  The problem is that the Fritzbox only allows https when setting up a remote access account with them.

Where did you get this?
I actually found:

  "For the following MyFRITZ! activities the HTTPS security protocol is used:
  - setting up a MyFRITZ! account [...]"

and

  "The FRITZ!Box generates its own HTTPS certificate. Because
  this certificate does not come from a certification authority
  preconfigured in common browsers, you have to confirm in
  your web browser or in the My
  FRITZ!App that the connection
  should be established nevertheless."

  From Fritzbox manual

It rather states (as I read it) that for the listed activities HTTPS is default/required. But, it also indicates that your router is quite capable of HTTPS. So you could just type the "https://" in front of your admin page URL and test it.
However you will get a warning about the not certifiably connection, but this still encrypts your traffic (as long as there is no Man-in-the-middle).
With my Fritzbox 7360 I'm capable of using the HTTPS protocol this way.


Is injecting malicious file with browser localstorage possible?

It is not standardized how a web browser saves the data it gets asked to store in localstorage. But it is very unlikely that it will be implemented in a way that it ends up as a valid executable file, and even when it would be, it is unlikely to be a file you or your operating system would ever execute. Security vulnerabilities in the implementation details of specific browsers are of course always possible, but the standard has no obvious ones.

The two stackoverflow questions you found are misleading.

The first one requires user interaction to intentionally save a file, and that file could come from anywhere, not just the users webstorage. Popping up a download dialog for an arbitrary file using javascript is web developer 101 knowledge (it's document.location = "http://example.com/malicious_file.exe" when you want to know) and any internet user should know better than to save and execute random executable files they get prompted to download.

The second works only on IE and only when the HTML page is loaded from the local filesystem, not from a remote webserver.


Is it dangerous to disable the IPv6 firewall built into many home routers?

Yes, it is dangerous to disable a firewall with out any compensating controls or replacement filtering. It is true that an internet IP address indexer for IPv6 has much more to cover, but it does happen. Sans has articles on this.

One of the issues here is that IPv6 allows for a direct attack on an internal device. NAT is not used (at least that is the intention of ipv6) so an attacker doesn't discover the router first, it is trying to send messages directly to the device internally.

Although there is less attention placed on attacking ipv6, it definitely is happening. In my day job we look for ipv6 on internal networks that are ipv4 based as signs of a breech.

A suggestion for an answer to the question of "if I turn off full blocking of ipv6 because I want to use it, what then?" would be to run through a pfsense box. Here is an article. https://blog.joelj.org/setting-up-pfsense-with-ipv6/
This would allow only devices and services that you want exposed to the internet open, instead of all devices on your network, some that may have vulnerabilities or mis-configurations.


How safe is it for an app to trust a click on a link in an email?

I would create tokens (Some random hashes or GUID) for each intended user and pass that in the query string to identify the individual users. Kind of like a temporary password. Putting this on the query string is convenient for the user. Making the GUID, or token temporary or for one time use will reduce sharing. Your only concern after this is if your users need to edit or amend their response to your question after the fact. I would send the question ID along with the GUID. As an example:

http://example.com/thread/27?AHG324y6CVSA452aw34aF

Where http://example.com is your domain, thread is your controller/action (MVC) and 27 identifies the thread, or question being asked. You can then use their  token AHG324y6CVSA452aw34aF to identify who submitted the answer. (Unless your going for anonymity then that is up to you, but users wont trust you, or rather, I wouldn't trust you, with this approach).

Sounds like a fun project.

EDIT:

Important note: GUIDs are unique, not random so they should not be used in this scenario.


Why are unsigned Java applications blocked?

A few reasons:

Buying a certificate would leave a paper trail, allowing malware to be more easily backtraced to the person that paid for the certificate.
It increases the barrier to entry for creating malicious Java applets, because of the cost.
I believe CAs (e.g. VeriSign) require you to provide evidence that you are a legitimate provider of software.

That being said, you're touching on a major problem with PKI: you have to rely on CAs being infallible and trustworthy.


Yes, this leaves you vulnerable to attacks involving diffing the ciphertexts on the two drives. Instead, you should create a new encrypted container on the backup drive, and then copy only the inner image from the primary to the backup.


The answers you're looking for can be found in the Cryptsetup documentation, but to summarize:

LUKS uses PBKDF2 to derive a "slot key" from your password, with a default iteration count sufficient to take one second on the computer that created the LUKS volume.
This "slot key" is unrelated to the key used to encrypt your data.  It is only used to decrypt a copy of the volume master key, which is then used to encrypt/decrypt the data.
You can have up to eight different passwords for unlocking the volume.
Each slot key can have its own derivation function.  If you find that one second of PBKDF2 doesn't fit your needs, you can add a new password with different parameters and erase the old one.
There is no support for changing the encryption on a LUKS volume after it has been created.
When creating a LUKS volume from the command line, you can specify the cipher used.  The default is "aes-xts-plain64" (AES-128 encryption in XTS mode with no hash function).  LUKS does not support layered encryption algorithms.
LUKS does not support hidden volumes the way Truecrypt does, but given that everyone and their dog knows about Truecrypt's hidden-volume support, these "hidden" volumes can't be considered at all secret in the real-world (as opposed to the information-theoretic) sense.


Can DES-based hashed password be recovered if salt is known?

John the Ripper works by trying out possible passwords, very quickly. It will not always break a DES-based crypt, or at least not easily.

With the DES-based hashing function, passwords may have up to 8 characters, and only 7 bits are used for each character (the upper bit is ignored). Considering that the password is typed at some point by a user on a keyboard, one can assume that there are 95 possible values for each character (ASCII characters from space [32] to tilde [127]), hence 6704780954517121 potential passwords (that's 1 + 95 + 952 + 953 + ... + 958). It is quite a lot; enumerating all possibilities on a PC will take at least a few weeks. But it is still technologically feasible.

DES is an encryption function, but the DES-based crypt is not DES; the internal function is altered (by the salt, namely), executed 25 times, and, more importantly, the roles of the key and the message are swapped. The end result is that the name "crypt" is improper (though traditional): this is no longer an encryption function; it should be called the "DES-based hash". What this means is that there could be (and indeed there are) two distinct passwords which hash to the same value (even if they use the same salt). For instance, this blog post shows that with the salt "hi", both "cqjmide" and "ifpqgio" hash to the same value "hiH9IOyyrrl4k" (the blog post claims this to be the first publicly known such collision, which shows how much the problem is interesting since it is not hard: these are 64-bit values, so the cost of finding a collision is about 232 invocations of crypt(); that the first published collision appeared only in late 2010 just proves that nobody actually tried before that).

(Note: contrary to what the blog post says, the possibility of finding collisions has no influence whatsoever on the security of the password hashing system. The DES-based hash should not be used any longer not because of the ease of producing such collisions, but because it has too small input and output spaces, and is too fast.)

Consequently, from the salt and hash alone, there is no way to pinpoint "the" password, because the information is just not there. Through enumeration of all possible passwords, one can build the list of matching passwords, but there is no way of telling which is the one the user thought about. However, and that's the important point here, the machine which uses the result of the DES-based hash in a password verifying system cannot tell either: any password which matches the salt and hash value is a good password, as real as any other. If the salt and hash are "hiH9IOyyrrl4k", then both "cqjmide" and "ifpqgio" are accepted: even if you thought your password was "cqjmide", I can still log in under your name by using "ifpqgio" as password.

Note, though, that the vast majority of possible hash values have a single matching password, hence exhaustive search will find that password and none other.

On a similar note, since only the first eight characters are used, you could have a 40-character long password, out of which the last 32 characters will be totally ignored by the DES-based hash. There is no way to recover those from the hash value since they are simply dropped and have no influence whatsoever on the computed hash.


A proxy server and VPN server roles are different on your scenario.

A VPN creates a new network interface that is on the same LAN as the VPN server, allows you to connect from the internet and use the network as if you were on the local network. In this case, you enable RDP only for the internal network and still can connect.

A proxy server is the reverse. It allows you, from the local network, to reach sites on the internet. It protects the internal network from attacks, by providing only one gateway to the internet and usually employing security measures, like filters, blacklists, scanners, and so on.

Mixing both does not make much sense. Unless the network you are currently connected have a forced proxy, it's not needed. And if you have to, a proper configured VPN will work even behind a proxy.

If the proxy is not trusted, it could MitM the VPN connection, decrypting the connection from the server and client, and changing/recording/replaying data. So if you have to use a proxy, pay attention to any VPN messages telling about mismatched fingerprints, invalid certificates and other security warnings. Other than that, it will work.


What's the best route to watch network traffic on our networks?

If your switch supports port mirroring, I would definitely go that route.

Port mirroring will essentially duplicate all traffic coming through the switch, and send it to a single port. You would then want to connect a machine to this port and run whichever packet capturing tool (such as Wireshark) for analysis.

I wouldn't want to go with the ARP poisoning route. This can slow down your network and if the machine sending out the spoofed ARP requests were to fail you could bring your entire network to a halt.


How secure is Libra considering Visa and Mastercard are behind it?

At the moment it is impossible to know how secure it is, because it basically doesn't exist yet. It will be launched in 2020. Also, everything that revolves around blockchains tends to be controversial, because the at the moment the "blockchain" is still a solution in search of a problem. So I guess most answers will be based on speculation, and this question might even be closed because it's too "opinion-based". Nevertheless, I'm going to tell you a few things to consider.

Libra is backed by a reserve of assets designed to give it intrinsic value. This is supposed to make its value stable, unlike BitCoins for example. This sounds like a good thing that is absolutely needed (who would want to use a coin that might lose half of its value overnight?). However, at the moment we can't know how well this will work.
Libra will start as a permissioned blockchain. This means that not everybody will be allowed to run a validator node. Citing the whitepaper: "To ensure that Libra is truly open and always operates in the best interest of its users, our ambition is for the Libra network to become permissionless. The challenge is that as of today we do not believe that there is a proven solution that can deliver the scale, stability, and security needed to support billions of people and transactions across the globe through a permissionless network."
The consensus protocol will not work correctly if more than one-third of the nodes get compromised.
The Libra Blockchain is pseudonymous and allows users to hold one or more addresses that are not linked to their real-world identity. But will this be legal? How about money-laundering laws? And taxes? Governments must be able to control the transactions, somehow. Pseudonymous doesn't mean anonymous. But if the blockchain is immutable, if the pseudonymous identifier is leaked, will an "attacker" be able to see how John Doe has ever spent his money? We will see.
Libra is still in prototype stage. Libra is powered by open-source software, and the technology behind the Libra Blockchain will be free for all to inspect, use, modify, and distribute. However, it must not be very mature yet, because, citing the technical paper: "As Libra Core is currently in the prototype stage and does not power a blockchain with a currency that has real-world value, our security procedures are not fully in place."

Sources:

https://libra.org/en-US/white-paper/
https://developers.libra.org/docs/policies/security


The certificate used to authenticate the server and the client do not have to be issued by the same entity. It is totally possible for you to set the web-server up with a certificate you bought and in the meantime create your own Public Key-Infrastructure to handle client certificates.

The authentication process is not mutual, so this situation is possible and yet remains secure thanks to asymmetric cryptography and proper trust chain.


Can HIPS software practically be considered a form of MAC

No, HIPS is fundamentally different than MAC.

Mandatory access control (MAC) systems try to provide a robust foundation for security on your machine.  MAC systems are generally intended to provide a high level of assurance: they are based upon a rigorous mathematical theory, they try to provide strong guarantees, and they are intended to be secure even if the attacker knows how the MAC system works.  In general, MAC systems are generally intended to be very difficult for attackers to defeat.

Host-based intrusion prevention software (HIPS) tries to provide a best-effort mitigation against some common methods of compromising machines.  HIPS doesn't provide make any guarantees.  HIPS is not based upon any rigorous theory; instead, it is based upon a characterization of common methods that attackers tend to use.  A sophisticated attacker who is familiar with your HIPS can likely evade detection by the HIPS and render the HIPS worthless, but that is generally considered OK, because that is not the kind of threat that HIPS is primarily aimed at preventing.  HIPS are based upon host-based intrusion detection (HIDS) systems, which make a best effort to detect what attacks they can; the difference between HIDS and HIPS is that HIDS just detects (some) attacks, whereas a HIPS is a HIDS that also has some mechanism to try to stop any attack that the HIDS detects.  Since HIDS systems never claimed to be able to detect all attacks, it will also be true that HIPS systems cannot prevent all attacks.  The upside is that HIPS is a lot easier to deploy on a legacy system -- but it provides a much lower level of security, and a lower level of assurance.

Or, if you want to think in terms of an analogy: HIPS systems are like a blacklist.  MAC systems are like a whitelist.  Whitelists provide stronger security, but are also more restrictive, and thus blacklists may be easier to deploy.

In short, MAC and HIPS are in a different league from each other.  They're not in competition with each other, because MAC is intended and designed for a different context than HIPS.


How to protect Linux partition from access from Windows partition?

Best option is just to encrypt the Linux partition, e.g. with LUKS. That way the Windows 7 partition can't actually access any of the data on the other partition. Technically it can still read and write to the partition (there's no way to prevent this) but the data it sees is all encrypted.


I don't know of any such attack.  That doesn't mean no such attack ever existed -- just that nothing pops to mind at the moment.

There are a few others that are related, which you might possibly have been thinking of:

Back in the day, the "ping of death" was a malicious ICMP packet that crashed the recipient computer, but it did not allow execution of malicious code.  Cisco routers were also vulnerable to an ICMP-related denial-of-service vulnerability, but that didn't allow malicious code execution, either.

The closest example I can think of is the SQL Slammer worm.  Slammer was a single-packet worm: all it took to infect a vulnerable machine was to send a single malicious UDP packet.  The worm exploited a vulnerability in MS SQL Server, which accepted packets via UDP and had a buffer overflow vulnerability in the code that parsed this packet.  This vulnerability did allow execution of malicious code -- but it was not over ICMP.

None of these are similar to SQL injection in any way that I can think of.


What is the point of password rotation when we have 2FA?

Two factor authentication is so much harder to break than just a password, and token generators are getting stronger and stronger.

This entirely depends on your 2FA method your org allows.

If your org allow SMS for 2FA it has well documented vulnerabilities such as vishing the service provider and essentially stealing the phone number to receive OTP SMS to: https://www.youtube.com/watch?v=lc7scxvKQOo (2:29)

And/or attacking the protocols directly such as SS7 exploitation: https://arstechnica.co.uk/security/2017/05/thieves-drain-2fa-protected-bank-accounts-by-abusing-ss7-routing-protocol/

Then you have interception / phishing attacks which can allow circumvention of 2FA methods as detailed here: Attacker circumventing 2FA. How to defend?

The only "saving grace" at this time would be using FIDO U2F however (https://fidoalliance.org/) where supported has not AFAIK had a compromise on record (if anyone is aware of circumvention for FIDO U2F please comment).

  Why are we worried about the quality and rotation of passwords when we can just use 2FA and be done with it?

Password complexity is still important and I wrote about this (using some napkin math) here https://blog.oneiroi.co.uk/passwords/security/something-you-know/passphrase-or-complex-passwords/ and should not be discounted as "not required".

If you set your password to 12345 (one of the most common passwords in 2016) it's effectively one less layer of protection an adversary / hacker needs to contend against (as it is trivial to circumvent at that point).

Security in this case (and most cases) needs to be applied in layers, no one layer being more or less important that the other (your wanting to make it as difficult as possible for an adversary/hacker).

Password rotations is as far as I am concerned a "stop gap" measure usually where organizations would or could not apply an additional layer in 2FA or MFA.

Which then many standards jumped on the proverbial hype train and now require this.

There are studies and articles which suggest that regular password changes actually work against the security of the account due to users developing bad behaviors (the problem of the human). (e.g.https://www.wired.com/2016/03/want-safer-passwords-dont-change-often/).

AFAICT standards have not taken these into account at this moment in time.

Assuming your org serves a client base, you may have clients which require in the business agreement between your org and the client there to be password rotations.

Sure it's a PITA but is it really a crusade you feel you can take on without detriment to the org you work for and perhaps loosing a few clients along the way ?

And really if there is no client paying the org, in all likelihood you will not at the end of the day have a job.


Trying to replicate SQL injection attack

There's a lot of ways to get information out of databases through SQL Injection (similar techniques can work for other injection avenues as well).

First, there's error based - you deliberately create invalid request and the webpage helpfully hands you back a full SQL statement with what's wrong with it.  You can use this to guess table names and confirm whether you are right.  This one only works with websites that are not properly configured - 500 (server error) pages should NEVER return debugging / stack / database information, ever.  That data should be logged and a friendly, non-specific message should be given to end users.

Second, there's taking advantage of queries that display data.  If you've got a page that is displaying rows of data, the attacker can tack on a Union and another select, guessing the number of columns that the query is expecting (you can do this by trial and error) and the database tables that provide table/column data.  This will provide them all the tables and their columns and they can use that information to extract further information or do damage with updates and deletes.

Third, if you can't actually get any data out (because the only injectable statement doesn't return any data (an update for instance), you can do what is called Blind SQL Injection.  You can cause the database to leak information just by its success and failure - you can guess table names and see if the update succeeded or failed.  You can even guess column values and use that to leak data - is there a user whose name starts with a? b? that the second character is o?  that the third character is b?  Oh, there's a user named Bob.  Obviously, this is best scripted, since leaking quantities of data this way takes a LOT of requests, but not as many as you might think.  Blind SQL Injection can also be done timing based rather than error based - basically if a condition is true, they put a sleep in and use the difference in the query execution time to determine if the condition was true or false.

Hopefully this will help you find more information on each of these.  There are likely variants and other techniques that I am not familiar with - my role is not primarily pen-testing, but rather secure software development practices.


Is there a term for Authorizing before Authenticating? Is it even common?

I have seen systems that filter by a list of allowed IP addresses first, so in order to even attempt to use an authentication method you have to be coming from a specified IP address or range.  This is similar to what you are describing.  But in general, authorization refers to deciding what an authenticated user can do, and so logically comes after the authentication step - except when anonymous access is allowed, of course.


Evaluation board for side channel attacks

If looking to use off-the-shelf boards, you can potentially use the H-Field probe solution. See https://wiki.newae.com/H_Probe_Usage for an example of H-Probe usage, there are lots of standard COTS probes/amplifiers around.

We've also got a FPGA target board that "just works" with ChipWhisperer, see https://wiki.newae.com/CW305_Artix_FPGA_Target . It's similar to various other FPGA boards, it's using Artix 7.

Any of the FPGA boards let you customize the crypto, of course though it may be some work to implement your algorithm.


Information in EXIF are not free data but have data types. The GPS position information are rational data types expressed as exactly 8 bytes. This means that you cannot put arbitrary string information in it but only floating point numbers.

It might make sense to restrict these values further to sane values. Given that you only want to keep the GPS information of the EXIF metadata it makes sense to extract these, remove the original EXIF data block and write a new one with only the GPS information in it as long as they are within a sane range. There are libraries in a variety of programming languages to do this.


GET and POST request vulnerable to CSRF attack?

Yes, both GET and POST are vulnerable to CSRF.
However, RFC 7231 states

the GET and HEAD methods SHOULD NOT have the significance of taking
an action other than retrieval. These methods ought to be considered
"safe".

Therefore, if a website has kept to the standard and only implements "unsafe" actions as POSTs, then here only POST requests are vulnerable. However, many websites don't do this for all of their "unsafe" actions - for example, logout functionality is often overlooked (although this is usually considered very low risk).
Although PUT is safe without CORS, it isn't the correct method to use in most cases. PUT is idempotent, therefore the request can be replayed without consequence, whereas POST is not. Not that any browser will arbitrarily retry PUT requests, but it might be an issue if some JavaScript does it on an event expecting no further state changes, for example. If you're implementing CSRF protection, a good method for protecting XHR requests is to add a header such as X-Requested-With to your requests and then validate this header server side. You could combine this with a random value that is checked server side to add further protection in the case of browser plugins like Flash containing vulnerabilities that accidentally allow the header. See this answer and this one.


Email injection works exploiting the way a email server processes the requests. A typical email transaction works like this (S is the server, C is the client):
 S: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
 C: HELO USC-ISIF.ARPA
 S: 250 BBN-UNIX.ARPA

 C: MAIL FROM:<Smith@USC-ISIF.ARPA>
 S: 250 OK

 C: RCPT TO:<Jones@BBN-UNIX.ARPA>
 S: 250 OK

 C: RCPT TO:<Green@BBN-UNIX.ARPA>
 S: 550 No such user here

 C: RCPT TO:<Brown@BBN-UNIX.ARPA>
 S: 250 OK

 C: DATA
 S: 354 Start mail input; end with <CRLF>.<CRLF>
 C: Blah blah blah...
 C: ...etc. etc. etc.
 C: .
 S: 250 OK

 C: QUIT
 S: 221 BBN-UNIX.ARPA Service closing transmission channel

(got from here)
This is the case for sending a single email. But if you need to send several emails using the same SMTP server, you don't need to HELO again, just send another MAIL FROM and send the next.
An injection works by exploiting the MAIL FROM parameter, by including a full email message on it. For example, take this from address:
some-spammer@someplace.net\nRCPT TO: <spam-receiver@someone.com>\nDATA\nCheapo Viagra pillz\n.\nMAIL FROM: <legitimate-email@provider.net>`

For the mail server, there's two transactions occuring: the first one uses the concatenated overlong from address, and the second one will use the rest of the message your site intended to send.
This method is used a lot by spammers because they will use your bandwidth and your IP address to send spam, so you will end up banned around, not them.
How to solve this? Unless you are a good, security minded programmer, don't code your own email sending solution. There's lots of resources around that take care of validation, rate-limiting, queueing, and other tasks. Use them.


Could a virus force a phone to download an app and spread it?

Yes. This is plausible. What you're describing is worm-like behavior. App permissions are possible. But at some point it would probably need to exploit a vulnerability in the phone's software. It could be a chain of the app permissions enabling the exploitation of the vulnerability. In the real world, you sometimes need to chain together pieces like that to form a complete attack.
At the risk of splitting hairs, there is a distinction between a virus and a worm:

Virus - Infects a specific object like a file. When that file runs, it also runs the virus. The virus cannot run itself.
Worm - Usually a standalone program. Self-propagates across networks.

Credit to John Brunner for coining "worm" in The Shockwave Rider.
The most notable early example of an actual worm was The Morris Worm of the 80s. It's an interesting story. A logic flaw in the worm unintentionally led to a DDoS attack.


zenmap "intense scan plus udp" lan port has unknown port ,but lsof netstat doesn't shown those ports

...like 21524 ,41702,42639,51554,60331 those highest udp port

There is probably a socket waiting for data on this port for a short time only. Typical examples are DNS lookups  where each request should use a different origin port to deter DNS spoofing attacks. And this socket (and thus the port) is immediately closed after the DNS response is received. Thus you will not find it with netstat or similar if you look a few seconds later.


multi_console_command.rb (by darkoperator) uses the meterpreter APi cmd_exec() to execute a list of commands.

The metasploit API that allows us to use the shell interpreter is: session.shell_command()

Option 1:
build your own multi_console_command.rb module with session.shell_command() API
Option 2: build one resource file with those post-exploitation commands

My metasploit API cheat sheet list:
https://github.com/r00t-3xp10it/hacking-material-books/blob/master/metasploit-RC%5BERB%5D/metasploit-API/my-API-Cheat-sheet.md

My metasploit resource files cheat sheet:
https://github.com/r00t-3xp10it/hacking-material-books/blob/master/metasploit-RC%5BERB%5D/metasploit_resource_files.md


What does defense in depth entail for a web app?

I think it's arguably more important to understand what 'defense in depth' does NOT mean. It does not mean 'a long laundry list of impressive sounding controls, such as firewalls and encryption algorithms'.

Defense in depth is a technology-neutral term that means that two or more independent controls should have to fail before a system is compromised. E.g. holding your trousers up with belt & braces & string:-)

The key point here is 'independent' - if all your controls have common failure modes, or if only one of them needs to fail before you've lost, then there is no 'defense in depth'. For example if each of your tiers is accessible from the previous one via HTTP, and they all have the same vulnerability, then the firewall/DMZ setup is effectively rendered irrelevant since the attacker can use the same vulnerability to own them all.


TLS mutual authentication with self-signed client certificate

If you self-sign with a personal CA which you then put in your trusted root, then it's reasonable. If you self-sign and then just ignore all CA errors, that's essentially useless. You offer no security in this scenario outside of passive traffic monitoring.

Adding client certificates to the mix only protects the server from unauthorised access attempts. It does little to protect against someone impersonating the server.


How effective are firewall rate limiting rules for slowing down brute force and DOS attacks?

Personally, I use fail2ban to stop bruce force logins. Brute force tools tend not to open many parallel connections.

As for brute forcing HTTP logins, your connection limiting rules will depend on how many parallel connections your web applications requires. If you set it too short, your legitimate users won't be able to use your service.


I would say that the biggest risk exposing RDP to the internet, assuming your machine is fully patched, is the possibility of brute force attacks. If you're username is Administrator and your password is Password1 you're going to have a bad time.

Now with that said, I have run some boxes in my day with RDP exposed on the internet on a non-standard port and brute force attempts dramatically decreased. The fact you've added two-factor authentication means that you've reduced your attack vector significantly (though you should still use a long and complex password).

I would say that your setup looks safe enough.


Using a HSM device for code signature generation

Yes. Of course the users do not need any access to the HSM at all. They only need the public key.

This is what is done with a smartcard and an x.509 certificate. The certificate is handed to other users. They get the certificate as a file. It contains the public key. Usually they do not know anything about the private key.

The private key could be generated on a smartcard or HSM.


Can Android 5's own device encryption mechanism be exploited by a malware?

Okay, the issue was in a corrupted filesystem. Whether this is caused by a software or hardware issue I don't know. So when android booted it interpreted a corrupted ext4 data partition wrongly as being partially encrypted.

What I did to fix was following this comment on reddit here

Quickly summarized:

boot into recovery, start adb from a linux system, pull the partition, fix it locally, push it back:

adb pull /dev/block/mmcblk0p12 data.img
sudo fsck.ext4 -y data.img
adb push data.img /dev/block/mmcblk0p12


SSH: What's the difference or interplay between /etc/ssh/[host files] and ~/.ssh/[public key]

Host keys authenticate the server to you, your keys authenticate you to the server.

The SSH Host Key provides a fingerprint that you can use to validate you're connecting to the server you think you are.  You manually verify the public key fingerprint you're presented during your first connection, then you save it.  For every connection after that, the server sends you something which proves it holds the private key that matches that public key, so you know it is the server that you manually verified that first time (...because only that server has that private key).

This is completely separate from the key pair that you use to authenticate yourself to the server.  They're both key pairs, yes, but held by different entities, for different purposes, at different points in the connection process.

In all, the SSH connection requires two key pairs -

Your Client software checks the Server's (host) public key against data the server sends encrypted with the host private key.  This requires you to have a copy of its public key, which you're handed at the first connection and your client stores if you approve of it.
The Server checks your authentication data encrypted with your user private key using the copy of your user public key that it has a copy of because you put it there (or had someone put there for you).


I figured out that problem is about the format of snort output, the logs that I could read is alert logging, the logs that I can't read area unified2.

  Unified2 can work in one of three modes, packet logging, alert logging, or true unified logging. Packet logging includes a capture of the entire packet and is specified with log_unified2. Likewise, alert logging will only log events and is specified with alert unified2. To include both logging styles in a single, unified file, simply specify unified2.

https://www.snort.org/faq/readme-unified2

Thx


If we enable the debugger with this code:

app = flask.Flask(__name__)
app.debug = True

That only enables the debugger with the built-in dev server. To use the Werkzeug debugger with another WSGI server, we have to explicitly include the middleware:

from werkzeug.debug import DebuggedApplication
from waitress import serve
app = DebuggedApplication(app, evalex=True, pin_security=False)
serve(app, listen='*:8080')

When you do this, with evalex and pin_security options as above, the app is trivially vulnerable to remote compromise.


What kind of factor is a physical signature?

I would consider a physical signature a biometric, albeit a pretty weak one. It isn't really something you have, since unlike a physical token, it cannot be stolen, or given to another (or, under most common circumstances, lost).
It isn't really something you know either, even if an attacker knows exactly what your signature looks like, he cannot necessarily reproduce it.

The idea behind a signature is individuals have different idiosyncrasies in their handwriting that is relatively difficult to replicate. Unfortunately "relatively difficult" is very far from impossible.

Edit:

Some of the other answers to this question make a good point: Most of a time a signature isn't actually used as a for of authentication (in the usual security jargon sense). When it is used as an authentication factor, however, it would be a biometric.


Can I be identified across different access points to same ISP?

Identification via MAC address is only possible, if your ISP can "see" that. MAC addresses are only seen on the client that are in the local ethernet collision domain, i.e. if they're on the same switch (simply put). This, of course, includes the router that acts as a gateway.

So, if at home you have a router that your ISP can't access, your MAC can't be seen beyond that router. At a public access point, which acts as a router, it can be seen by the owner of that AP - likely that ISP.

That being said, your ISP is likely to be able to recognize you in different café's, but not at home. In order to avoid this, you'd have to spoof your MAC, which is not easy and requires root access.

That much about MACs, someone who wants to identify you is very likely to use some other kind of identification that can be tracked across routers. Cookies, browser fingerprinting, just to name two. There're more than that and it's hard to counter all of them.

One thing I'd like to add:

Though tracking by ISPs is an issue, it's not the kind of tracking that'd worry me most. ISPs are usually specialized on providing you internet access. That's probably because the scope where an ISP can track you, is always limited. As soon as you're in another country or simply logged in to a friend's Wifi, your ISP has little chance of seeing your traffic at all.

On the other hand, if you have, say, a Google or Facebook account that you use across multiple devices - which most people do and of course they're always encouraged to do so, it's much, much easier to use that information for tracking you - and that's only the tracking that's officially done and most likely legal. There're many more trackers out there that have at least a questionable legal status - at least in some countries - and while you actually can refrain from using Google or Facebook (though avoiding them completely is difficult), it is even harder to avoid trackers that you may not know or think of.

Remaining completely anonymous on the internet is a very hard thing. TOR may be a good choice against just about anything but the NSA, but there're issues, too, and you have to know what you're doing.

Yet one more thing:

Most trackers do not know who you are. Usually they do not care. They're not going to write you a letter, so they don't need your address - letters are too expensive anyway. Same thing for phone calls. The police may look for that if they think they have to, but usually that's about it.

For a tracker it's enough to know something like that: "This person - likely male, probably married with an annual income somewhere around $100.000 has been searching the net for information about pregnancy tests. Therefore he might be interested in buying those as well as baby toys, baby clothing, baby insurance, maybe a bigger car and so on, so if that person loads one of our advertisements, it might be a good idea if it's from one of those categories. Since he lives somewhere around Syracuse, N.Y., we may also add some stores for baby supplies from that area." Try it. Google those things a bit and watch your banners miraculously change. It worked in my case. :)


Random persistent Gmail password requests from Google

Based on what you provided we can see that the Thunderbird icon is active.

If it was configured to synchronise with Gmail account, and the authorisation was never performed or revoked, the connection is refused by Gmail service and Thunderbird requests an OAuth authorisation.

If the above is true, there's no indication this authorisation request is illegitimate.

If Thunderbird is running constantly or checking the emails periodically, the message may appear on each connection attempt.

Because the authorisation is performed within an embedded browser session within Thunderbird, it doesn't behave like a regular browser, where you can check the certificate by clicking on the padlock icon.


"No identity information" alert on gmail

Go here: https://grc.com/fingerprints.htm and put in mail.google.com

Then compare the fingerprint the server shows with the sha-1 fingerprint in your cert.

grc.com and my SSL cert both tell me 84:45:3A:42:E0:2D:3D:50:00:30:C1:2D:D3:2C:26:06:6F:78:AB:3D and a bunch of people in chat agree.

If yours matches, then it is mathematically impossible that someone is doing something nasty, unless they have a true quantum computer that can trivially factor large integers more efficiently than a digital computer (which, if true, would make Heartbleed look like an echo ha ha "virus"), or unless they actually used a vulnerability against Google's servers (fairly unlikely now that Heartbleed has blown over).

You can trust the connection is end to end to Google based on the manual and independent verification of the fingerprints.

However, I believe Gmail has mixed passive content which is the reason why Firefox doesn't consider it to provide "identity information". A full explanation is on Stack Overflow.


How would one go about becoming a Security Researcher

To become a security researcher (or any kind of researcher) you choose a security topic and master it.  Learn everything about this topic,  and if you explore this topic far enough will find something new.

To get a job as a penetration tester you need to prove that you can in fact break software.  How I did this was by obtaining CVE numbers and putting that on my resume....  But if you don't know how to break software in the first place you can't do the job and you won't be hired.

In the security industry right now web applications are king,  closely followed by mobile applications.  Master the owasp top 10,  hack DVWA and hunt for bugs in open source web applications.  Write exploits for these flaws,  report them to the developer and obtain a CVE number.


Twitter switching to 'mobile.twitter.com' after it detected the browser is outdated

Regarding #1:

Desktop-oriented sites often use newer and more demanding features than their mobile counterparts.

It is likely that your browser does not support some functionality that the regular site requires (or that its implementation of that functionality is non-compliant with standards, which would cause the site to render improperly).

You should update your browser regularly to improve its functionality and security.

Regarding #2

No. This is an example of a graceful fallback.

This means the application or service has intentionally switched to a less-functional mode instead of failing in an unpredictable or unsafe way.


How do I correctly check for a secure password?

If not mistaken, you are asking how strong the server password(s) should be. As said in the comments, you are the only one who can answer that.
Those pages should help you out:
SEC.SE
Wikipedia
Microsoft
Nist
Not in the question range
Your password(s) policies should meet the security requirements you have wisely established after assessed the risks. Here is a basic plain scheme :
        0 security           security requirements button        super secure
                 <------------------------[]----------------------->
user super friendly                                               Not user friendly at all

Here is the general idea : you have to define the security requirements button position. It's more or less a compromise between the ease of access and the security.


How to securely erase the free space on an SSD in windows 10?

Assuming that the SSD has a properly implemented TRIM function, then Free Space should already be wiped for you, this is what TRIM does as a side effect of preparing deleted/unallocated files for reuse in an SSD.

To check if TRIM is on in Windows, from a command prompt:

  fsutil behavior query disabledeletenotify

The response should be one of these:

  "NTFS DisableDeleteNotify = 0" Which means TRIM is ON.

  "NTFS DisableDeleteNotify = 1" Which means TRIM is OFF.

If for whatever reason you want to roll your own as it were, you can use any of a myriad of cleaning utilities or simply create a giant file of arbitrary data until you run out of space then delete the file.

That said, there are GOTCHAS to be aware of!

Wear Leveling – (Not an Issue)

This is an effect of SSD’s swapping physical storage cells with spares as the cells begin to wear out. Once swapped out, the old data in the cell is no longer reachable to be wiped. This is not a realistic concern. This data is beyond the reach of all standard forensic labs. The few that could perform the necessary chip off disassembly are rare, very expensive, and still have poor capabilities to reassemble the wear bits into anything coherent.

Windows Shadow Volume – (Big Concern)

Deleting and wiping files in Windows does not necessarily touch previous versions of those files kept by Windows for file recovery.

MFT and small files

Small files (in the under 1 KB range but varies) may be stored directly in the Master File Table instead of as their own file. This is important because when these small files are deleted, only the usage indicator is deleted from the MFT, but the MFT itself is NEVER deallocated.

Databases

Similar to the MFT, removal of an entry in a database does not deallocate the database file. Until that particular slot is reused or the database is compressed/vacuumed the data is potentially still there.


Use Public/Private key pair for password authentication

The main problem with your plan is that PBKDF2 is used for generating symmetric keys only. To generate a public/private key pair, you could potentially use the output of PDKDF2 to seed a random number generator and then use that RNG when coming up with the public and private keys. However, Javascript lacks the ability to seed the random number generator. So you'd have to roll your own, use a library, or generate the keys on the server.

I am struggling to see the point of all this, though. It seems like you are interested in using this mechanism to encrypt data in flight, but that is already taken care of by SSL/TLS. If you just want to encrypt data at rest in a manner where the server (and its administrators) are unable to access it, you could just use a symmetric key.


What do emails have to do with the spread of WannaCrypt?

Many organizations don't have SMB directly exposed to the internet, but SMB is widely used internally by organizations.

It is believed that the initial attack vector for WannaCry was /is a malicious email. Once a single computer on a network of vulnerable computers is infected, it is then able to propagate itself to other vulnerable hosts on the network via the MS17-010 vulnerability.


Is my computer trying to download something malicious from Dropbox?

If your system has been taken over an attacker could manipulate the install dates of any software, so anything you see on a hacked system must be treated with doubt. The IP address you listed is a valid dropbox IP, however that means nothing - if I was writing malware I'd seriously consider using dropbox to distribute it. It's robust, completely free, and people are likely to discount it as a threat vector: "Oh that's just dropbox, don't worry about it."

So it is entirely possible that the malware installed uses a dropbox labelled process to actually connect to dropbox and download latest versions of malware and operating instructions, although that scenario is not particularly likely. It is much more likely that this is actually a completely legitimate dropbox installation that you don't remember installing, and therefore a red herring. Unfortunately, there's no way to know for sure as once a system is hacked you can never trust it again. Your best bet is to wipe your system and start over.


Is changing pitch enough for anonymizing a person's voice?

A simple pitch change is insufficient to mask a voice, as an adversary could simply pitch the audio back to recover the original audio.

Most voice modulators use a vocoder, not a simple pitch change. The term "vocoder" is unfortunately rather heavily overloaded these days, so to clarify I mean the type that is most generally used in music, rather than a phase vocoder, pitch remapper, or voice codec.

The way this works is as follows:

The voice input audio (called the modulation signal) is split into time slices, and its spectral content is analysed. In DSP this is usually implemented using an FFT, which effectively translates a signal from the time domain - a sequence of amplitudes over time - into the frequency domain - a collection of signals of increasing frequency that, if combined, represent the signal. In practice implementations output a magnitude and phase value for each of a fixed number of "buckets", where each bucket represents a frequency. If you were to generate a sine wave for each bucket, at the amplitude and phase offset output by the FFT, then add all of those sine waves together, you'd get a very close approximation of the original signal.
A carrier signal is generated. This is whatever synthesised sound you want to have your voice modulator sound like, but a general rule of thumb is that it should be fairly wideband. A common approach is to use synth types with lots of harmonics (e.g. sawtooth or square waves) and add noise and distortion.
The carrier signal is passed through a bank of filters whose center frequencies match that of the FFT buckets. Each filter's parameters are driven by its associated bucket's value. For example, one might apply a notch filter with a high Q factor and modulate the filter's gain with the FFT output.
The resulting modulated signal is the output.

A rather crude diagram of an analog approach is as follows:

The audio input is split into a number of frequency bands using band pass filters, which each pass through only a narrow frequency range. The "process" blocks take the results and perform some sort of amplitude detection, which then becomes a control signal to the voltage controlled amplifiers (VCAs). The path at the top generates the carrier waveform, usually by performing envelope detection on the input and using it to drive a voltage controlled oscillator (VCO). The carrier is then filtered into individual frequency bands by the bandpass filters on the right, which are then driven through the VCAs and combined into the output signal. The whole approach is very similar to the DSP approach described above.

Additional effects may be applied as well, such as pre- and post-filtering, noise and distortion, LFO, etc., in order to get the desired effect.

The reason this is difficult to invert is that the original audio is never actually passed through to the output. Instead, information is extracted from the original audio, then used to generate a new signal. The process is inherently lossy enough to make it fairly prohibitive to reverse.


Verifing the first link in the apt-get verification chain

The Debian keyring is shipped with the distribution installer, so you get bootstrapped your repository trust by the installation medium. This also applies to (probably) all other Linux distributions relying on OpenPGP/GnuPG for verification in package managers.

If you don't trust your installation medium, you should verify it by any of the means provided (fetching it from a trusted source, comparing with others, checking the OpenPGP signatures issued, ...).

If you want to construct a trust path into the Debian keyring manually, find some Debian developers and verify their identity/sign their keys. Usually, they will gladly meet with you if asked nicely.

  Wouldn't it be better if every 'repository creator' (like debian, ubuntu) had an easily and secure accessible https page where you can easily compare your local key to, instead of digging through the WOT in order to hopefully find a convincing link to the debian project?

There are people around that do not trust HTTPs and the hierarchical trust system for some (valid) reasons (but this is far beyond this answer, and already discussed lots of times) and prefer to rely on the decentralized OpenPGP web of trust, especially for bootstrapping trust.

In the end verification boils down to finding a trusted CD image source, anyway.

  But I know none of them. To be fair, three of those four are heavily signed by a lot of people. But I don't know any of them either.

Basically, you'd have to start your trust network somewhere (by meeting with others already connected to the web of trust, verifying their ID and signing their key), and go on extending your personal view on the web of trust by recursively selecting people you want to trust until reaching the Debian signing keys. For sure, this is not a trivial task.

Deciding whether to trust an HTTPs page suffers the same issues: again and again, there are reports of hacked and broken certification authorities. Do you know all of those hundreds of CAs, and do you trust each of them? They're all trusted and can issue valid Debian certificates!

  Bonus question: Is there a possibility to 'verify', that a package is the result of a build process from a specific sourcecode you can look at?

Debian promises you by signing the packages that it was built using the release file from respective Debian sources. The packages are build on build servers and signed by special keys, this is nothing the individual Debian developers do manually.


Free SSL Certificate when encryption is needed and not trust?

You can try StartSSL who will issue you a free SSL certificate that will be trusted. I use one of their certificates on my blog and yes, it really is free. Their site doesn't have the best user interface admittedly, but if you can live with that, this sounds like your best option.


Possible physical interface attacks on a server

Companies like Amazon (AWS), Microsoft (Azure) etc are all ISO XXX compliant, have strict security rules (I guess). Now neither you nor they can prevent a malicious employee who has access to the data center to harm/hack the hardware. But it can be detected...

One way I can think of defence is to encrypt the disk at rest.

The rest is in the hands of the attacker.


The value of a Live USB or Live CD for secure transactions comes from the fact that they create a non-persisting in memory system based on a read only ISO image.  That prevents all malware attacks to the local file system from being effective beyond the single session of the attack.

Upon reboot nothing from any previous session exists as it is all recreated again from that same read only ISO image that started previous session in memory.  That fact also prevents patching of a Live USB stick.  While the system might act as if it were taking a patch during the session there would be no persistent change in the media thus no updated behavior on the next boot.

You are right to want the latest browser etc. for your session so you are faced with two choices.  You could update your browser every time you boot knowing it would not persist or you could periodically update your ISO image by creating a custom Ubuntu Live USB using their tools and instructions.


Computer Virus Phylogenies algorithms - pseudocode?

Yes.  You are looking for Ancestral Recombination Graph (ARG) algorithms.  ARGs are the natural extension of phylogenies (trees) to DAGs.  ARG algorithms tend to be exponential algorithms, while phylogeny algorithms are polynomial.  This means that the dag problem appears to be significantly more difficult than the tree problem.

Please see the book:

D. Gusfield. Recombinatorics. MIT Press. 2014.

https://mitpress.mit.edu/books/recombinatorics


What is the impetus for major sites being HTTPS-exclusive now?

HTTPS is the easiest solution to a large number of security problems:

Every form of Man In The Middle attack is completely impractical over an HTTPS connection (you'd need to either break SSL or hack into a certificate authority). This includes protecting your users while they're on public wifi.
If any page isn't secure, and a user clicks a "login" link (which is presumably HTTPS), an attacker could replace it with a link to an insecure version that steals passwords. The only secure way to do this is either to serve the whole site over HTTPS or make sure users pay attention to the URL bar. Only one of those two options is possible.
Since all of your pages are secure, you don't need to think about which pages are secure and which ones aren't (user clicks login -> redirect to HTTPS version -> user logs in -> redirect back to HTTP -> user goes to their profile -> redirect to HTTPS...).
Modern browsers give mixed content warnings if an HTTPS page contains insecure content (styles, scripts, images, etc.). Most browsers treat this kind of page as if it's not secure at all (showing the scary red URL box). The easiest way to make sure you never run into this problem is to just serve all of your content over HTTPS.
If you're HTTPS-only, you can enable HTTP Strict Transport Security to further reduce vulnerability to MITM attacks (once a user has been to your site once, their browser will always choose the HTTPS version, even if directed to a http:// URL).

Honestly, I don't know why anyone doesn't enable HTTPS. It's completely trivial and it can be free.


ms-appx-web:// is an internal scheme of Edge for browser plugins, it's not a subject of CSP regulation. It's just an error in some Edge version or in the some plugin/extension.


What are some potential attacks that could be done to a website that doesn't manage url-encoding properly?

What you want to achieve is to enforce some security to /private/ and otherwise serve content freely. Login page shall be outside private.

Servers who handle path based security know how to handle the escapes. What they look for is to bring both the path and the pattern to a "canonical" form. This way, they make sure that they compare slash with slash and not with it's URL escape.

Usually declarative security beats programmed security. This implies that testing path is done in a single place, outside the application, in a 3rd party library written with security in mind. Odds are that the ones who wrote the library were aware about the fact that an URL may contain escapes. Another advantage of declarative security is that it doesn't clutter the code so much. We will not have things like:

delete_entry() {
if (rights.check("delete"))
   actually_delete();
 else {
   log_failed_attempt();
   throw new SecurityException("Not allowed to delete, the attempt has been logged.");
 }
}

A distracted programmer may forget the check for one single action. Rather, have an annotation system of "actions" that will be checked by a caller. If the security handler is missing, fail the call at runtime, this means the programmer has forgotten to "secure" the routine. "The free for all" functions shall have a @freeForAll annotation.

In your case, the server must enforce that /private/ is only served if the visitors have a specific token, which they cannot manufacture themselves. For example, it would be wrong to check for a cookie with the content "authenticated:true", as the clients may generate such cookie without visiting the login.


Man-in-the-middle attack by impersonating a hidden SSID

The attack as you described it is not possible. This is the impossible part: "that password you've provided me, that'll do just fine". In the Wi-Fi protocol, the client doesn't send the password to the AP. Instead, both the client and AP derive an encryption key from it, and they mutually authenticate by making sure they can understand each other's messages.


Believe it or not the modem isn't usually the attack vector because they often need physical access to be hacked. A wireless router is usually the attack vector because it opens itself up. If you're going to be the safest you can, you'd get a router(either wireless or wired) and put it between you and the computer. These extra jump steps make it harder for people t find your computer without knowing the exact configuration and often make you safer. To make it the safest you can get though I'd suggest a firewalled router, and if it is wireless and you don't need the wireless, turning off wireless. This is usually the best practice to protect a single wired connection in a residential environment.

Of course you could also go the extra mile and set up your own PF-sense box and just connect to that from your modem to your computer. But at that point you're literally building a router.


Modifying credit cards to increase security

The signature line matters, even for chip and pin.  Chip and Pin verifies the card is present, it doesn't verify the authorized user is.  The point of the signature line is to verify you are actually you, even if very few people actually check this properly.  I actually leave my card unsigned to see if people properly ask for ID.  I've only ever been asked for ID about 3 places.

Removing the visible credit card number, magnetic strip and CSC/CCV code should improve security though and I can't think of any case where a vendor would need to see them, though alterations to your card may make the vendors more suspicious as it isn't what they are used to.


Capturing SSL Traffic from My iPhone and Decrypting it

First we need to address the elephant in the room. Unless you have permission to test these systems or own the devices, applications, and systems you are testing, this activity may be illegal. Now, with that out of the way:

In order to decrypt SSL (HTTPS) traffic, you'll need to either have a copy of the server's private key or generate your own cert / private key and use it while MitM'ing the traffic. Note that the second option will result in cert errors for the client that he/she will need to [by default] accept in order to continue interacting with the site/application.

Your title says from your iPhone but your question says using Win7 and Kali. I'll stick with Kali for this answer because it's the easiest thing to get you started.

One Approach with Kali

By default, Kail comes installed with a web proxy known as Burp Suite. <-- That link will take you to setting Burp up to intercept SSL traffic. You can MitM traffic by configuring your browser to proxy through the localhost (usually on TCP/8080 by default). Then you can browse to the site (accept the SSL warning) and see your traffic decrypted in Burp.

A More Complicated Approach - Will Work for Smartphones Too

You'll need to generate a certificate and install it on your devices to be able to decrypt the traffic later. You then need to proxy the traffic through a device capable of doing the packet decryption/inspection. A better overview of the process can be found here. That link is for a specific program/setup, but the process is pretty much the same no matter what the specific implementation is.


Protecting WordPress from a single machine DoS (either in network/web level)?

A good defense against DDoS attacks (and smaller DOS attacks) is using cloudflare. They have a free tier for websites that offers an "I'm under attack!" mode. Read more about it Here.


How secure is full-disk encryption technology on LineageOS, or Android phones in general?

Simplified Explanation
Both Android and Lineage use the same encryption. Both are secure enough against the threats it is designed to protect against. Specifically, an attacker with physical access to a powered-off phone.
Bad analogy time:
Think of device encryption like a document safe. You have the only key.
Think of the lock screen like the security guard you hire to keep people away from your safe.
If an attacker wants to read your documents, if your safe is locked, the security guard is irrelevant. There is no way for them to get into the safe to get your documents. This is when your phone is powered off.
When you go to read your documents, you send your security guard off for lunch, as you are watching after the safety of your documents now. You use your key to unlock the safe. Now you can read your documents. This is when you are actively using your phone.
You have a full work day ahead of you. You step away from the room, leaving the safe unlocked. In a few minutes, the security guard comes back. They will prevent anyone else from getting into the room. This is when your phone is turned on but locked with a lockscreen password.
Your security guard gets a call from their boss. There is a search warrant out for the contents of your safe. They are instructed to allow the police into the room with the safe and keep you out of it. This is Google or other device management software remotely unlocking your phone or even changing the lockscreen password.
They could even remove your documents from the safe, putting them into a new safe, just in case you manage to come back and attempt to lock your safe again. This is Google changing or removing your encryption password, which you will note is only possible because the safe was already unlocked. Had you locked your safe/encrypted your phone, they would need your key, which only you have, to do anything.
A Little More Detail
If I remember correctly, and if it has not changed since I learned about it, the device encryption key is randomly generated and actually stored on the device. This encryption key is then itself encrypted using a mix of your supplied password/PIN/pattern and some device-specific hardware-backed information that is hard to access without destroying the device (and hopefully the data as well). When you turn on your phone, you supply the password to Android, which lets Android decrypt the encryption key, which it can now use to decrypt your data as needed, until you power off your phone again.
Modern Android devices come already encrypted. They use a hard-coded default password mixed with the device-specific stuff to encrypt the encryption key. This lets you use your phone right away out of the box without entering a password. It also lets you set your own password without waiting for all the 128+ GB of data on your phone to be re-encrypted with a new key; the same key is used for encryption, that has not changed, you just re-encrypt the key itself with a new key.
Since the encryption key is already decrypted while your device is powered on, it is easy for Android to just re-encrypt that key whenever it needs to, with a new password, or with the default password again. This is exactly what happens when you change your password, when you enable an accessibility service, or theoretically when Google gets a lawful order to do so (I have not heard of this last one happening). The lockscreen is only software-enforced, if someone has control over the software running on the device, it could easily be bypassed. There are occasionally software bugs (especially in unofficial Android ports like Lineage that mess with the lockscreen behavior) allowing lockscreen bypass without any special access. Without those bugs, or if the phone is off (the encryption key is still encrypted), either special software must already be present on the device, or an automatic update must push such software without user intervention to allow access.
Here Lineage and similar ROMs provide a trade-off:
With Lineage, assuming you do not have Google's services installed (or any other software with similar access or exploitable bugs), there is not any preloaded software or automatic update mechanism that would allow lockscreen bypass or changing encryption passwords. The security guard does not have a phone, so they never get the call to allow the police inside. However, with Lineage you must unlock your bootloader to install Lineage in the first place.
Back to the bad analogy: a locked bootloader is like tamper-proof features on the safe that automatically incinerate the contents if someone removes them. The tamper-proof features prevent affixing anything to the lock, so an attacker cannot attach a device that captures a mould of your key when you insert it, or fit it with some automated system that can somehow try keys much faster than a person casting one key after another and trying each manually (ok, the analogy is stretched to its limit here).
When you unlock your bootloader, all your data gets wiped. But the phone simply will not run any software other than from Google or your device manufacturer, unless the bootloader is unlocked. An attacker probably would love to install a low-level keylogger or a password brute-force cracking program that runs before you even enter your password, but cannot, because the bootloader is locked. If they unlock it to install their software, the data they wanted is now gone. So, they're limited to manually entering one password after another, and can't really speed things up.
But Lineage requires an unlocked bootloader. An attacker with physical access could reboot to "recovery" (the same method used to install Lineage) and then install whatever they want without decrypting your phone first. Then they can either give your phone back and capture your password when you enter it, or brute-force your password in software, guessing thousands or more per second instead of one every few seconds.
If you have a strong password (unlikely for most people, because it's a phone) you'll still be fine. If not, Google as a potential adversary may be preferable.
Note: it is actually possible to have a separate lockscreen password compared to your encryption password. There isn't a UI for it in the system settings (Lineage removed their UI due to flaws in the implementation a while ago), and it may not be possible on "stock" Android at all, but it's technically supported. This might make using a strong encryption password less onerous.
Update: File-Based Encryption
All the above was written with "full-disk encryption" (FDE) in mind. Older versions of Android used FDE, where after rebooting, you could not unlock and use your phone at all until you entered your password or PIN. But, newer Android devices almost universally use "file-based encryption", or FBE. With FBE, your phone boots all the way to Android's lock screen, where you can make and receive calls and see a few notifications before ever entering your PIN. This complicates the situation quite a bit, because the idea of FBE is that only certain files get encrypted with secret data: many of the files on the phone–specifically all files required to boot, make phone calls, and some other tasks–are left unencrypted, or encrypted only with data saved on the device and accessible to Android without user input (I'm not 100% clear on whether it is fully unencrypted or encrypted in an accessible way). In particular, if you're using an SD card with "adoptable storage", the SD card encryption key is available at boot without user interaction. Adoptable storage has been removed from many stock Android ROMs because it renders the SD card usable only on the device where it was formatted (which apparently confuses a lot of users), but is still present as an option in Lineage OS.
Revisiting the analogy, FBE is like you only keep a few of your documents in the safe. The rest of your documents are left lying around the room and rely fully on the security guard to keep away from prying eyes. You even have a locked file cabinet for some documents that won't fit in your primary safe (your SD card), but you leave the key for the file cabinet on a hook on the wall, rather than in the secure safe for which you keep the key.
Unfortunately it can be difficult to know which documents are kept in the safe and which are left out on the table.
FBE adds another trade-off to installing Lineage. In stock Android, there are normally no built-in features that allow ADB or any other methods to get files off the device until the device is successfully booted. While it may be possible for well-funded experts to do so, there are no official features allowing it, so your average petty criminal will not be able to get your data even if it happens to be one of the files FBE does not fully secure. Lineage and other ROMs are often installed with a special "recovery" image that allows filesystem access as a built-in feature. Even if you use a recovery without full filesystem access, such as Lineage's recovery, with an unlocked bootloader (back to that again) an adversary could easily boot whichever recovery they choose and access your filesystem that way. Thus adoptable storage and any other files not fully protected with encryption under FBE are more at risk with Lineage than with a stock Android image, which may outweigh the risk of those files actually protected by encryption under FBE from being compromised by backdoor access from Google or your phone manufacturer while your phone is already unlocked (e.g. in response to court orders).
All of this discussion is relevant only to the scope in which device encryption is intended to protect your data: i.e. when an attacker gains physical access to your locked device. There may be other security considerations that weigh into a user's decision to install a custom ROM, e.g. for out-of-support devices Lineage may provide protection from known network-exploitable vulnerabilities that have since been fixed by Google. But that just means there are more things to weigh against the trade-off in the security offered by device encryption.


Hash, encryption of file... key? Need help

This is a Base64-encoded audio RIFF/WAV file.

First you need to Base64-decode it (for instance, with YellowPipe's online tools) and you get (sorry for the one-line ugly format):

RIFFº WAVEfmt U€>Ä  ´qfact€©data| ÿó8Ä[ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿó(Ä_[ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿó8Äš[ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ§^X$BÁ!a³33û¸ŽÂÇ5»ÂÏ9Île¯=‚ˆmÒ4üÊ1>CP–È3ó]ö™#H„‘ †‚då'¨eÎpÉÎ Z4hä@ †Ûƒsœ2ç°@Ââ‚üÎ1?Åð–È.sô€º„&#FÞÁD¸ “'=¨B{PËœàêË‘@ƒ ¾ä¢… 6€ Á&*AÂŸL¨23    Rq¹-Eœà  H£c”™ÓìoLJÊ",aÉ/ÿ2ŒOðì%².4v(¼2I¤òàÊ"’ëMÐBX=Êd2@ÐêÌ‹‡‰ty’n˜Ã’%ñØ;òYdXX3"‚DrÿÌãüŠ«f 1 ”0sdG¿ÿÔîƒ&ïÍìpÑÍ¤‹ÿý7M h³ü@Qä4c r(‚““K£O&#65533; ´’×mc    ájÖ¡†hóyºH  1A äÐÀ˜Âr)cÿÌ£L–I†Vi¤Šä¢q£‡Y?©iW=²öMæäûâSQÌÙÞtu‚a¡1åÂñÁ-‡›PöVÙ³x7±˜ö[üðÊßÿ3ŒG‚S/§Ýyµ€½Œî™íÏ5mOÊâ-ÿ7ÿÞÆ3gþÖÙüÁPµ:Œ%Kˆ>Å”Èbms É8ô/H   !¬e~£óÔ¹Ü¿“Äkvû×ìJÈ~gqñïïMö—¬ßÿÌ£h{6ØyÇ¾½j‘zÜ5äH§k9vcya ·Ò46aûÎ¨õSø€µnë_ÿ`‰ÓGX¨Þ‘ÿ3ŒAQ.Uü’€ÁX20Fq²7þJ$Ž…?8›VBÊÊsŒÞOÔaÆ?§¬™ÿä8"ŸÙ€ (þ´Uè„FeÖEKN[³Š8Yµú¿ßôífâa‘øÚò¹ÿÀ 7ÿó(Ä1Šå–C siõ}½sb4§A¦NÔXqNü««Èº‚ BbCK7J°A£ÀxƒŸë8fŠ¯v¡ÎèÿÌã@<;—OMˆ/ÿH®‹…IÍ„e-˜1éJÞ¯F3E’Y†Ö2ý›öå>UXP†ÊIˆè¶@    C   áÅÄ':2;12y…pÌ*JJ!|'’¼«Y íÅ¤C«]peÌ¿ûÿÌ£Ì@«™8AIñ·¸¸žÓöBñÈÿüp} Ÿ•ÉÌÏë&gu·Ñk¶Ð8åP!eLË!ZBœ mæaU¿˜Ëe:Îç{ÿÌã¸T‹9@Á*ðýþêAA7‘k¹¦Î £ÞÍŽØ„b®Å¥ÿô¥®ê(ýÈåvÇÔ-!<û=¡ÿ*n9 1ó™~ 'øÚÜæà2ö^Éh‚„†;)E0f§Nnêè2ÿó(Ä92æPFüŒðM(Z?ä´Žõƒnˆý7;d`/1Î”ƒ1 YŠš²>dÆŒÌÁå™Oü å{”(’ÿó8Ä0Â á’FüÌ<Ñ¸8=ZƒßÏyPçÐ Ó©Ò×”  pN ¶þiCûêH²>g¢»u8PÃIœ4£¶1MÚ>0ˆÂnÿí(—º, ^5¨bXuèÿ½,@B€yU^à_ÿ2ŒDÁîmh˜HC ¶ÝZ}jß9ÊVü§þ{ŽÝpÎ†ÎrOÿÔ´Œªu:‹)F1†·3ÿDº:KÌüÎ1D ƒ´[¢ÁîQœQ:÷TÁ×ôÇ<x7ä)¨ttßF™Õ«T·SÍ™ÜŒ‹_àBeü²Ì•T…šªú?ý&´WÃ@p0:ÿ$¥5zžÞÄÚÑªØÿNÉêz°¸H_ÿÌ£ˆAÈ†ðe; Ào÷þÿÐÊT1P™ÝÁB‹‘Õÿýáÿï@Æ    ‚Ëk®?/Cñô`Íï’új.!öÿ3ŒEÁmF¨IÌ¾ÄÒHx>³„!-$‡!íI$µþ¦`1z &½ ›äL6ßÿýBäz0@¤ÄM˜ñ&.»w(j¨è“†ù÷1I£õ›$ýK<I.fh’Ûu-þµÊ,)]€Ÿ/ÿÿó(Ä{AÒâ,h

You can see from the header that it's a RIFF (.WAV) file. I don't guarantee that the output above is entirely valid, as I'm not sure how trustworthy YellowPipe's tools are.

And unfortunately I don't have sound on this PC so I cannot listen to it!!

EDIT:

You mentioned in the question that you only provided an excerpt. Obviously, you'd need to reconvert base64-decode the whole file to work on something useful, not just an excerpt.

If possible, please post the whole file to Pastebin, Dropbox, Google Docs or something like this.

EDIT 2:

It works perfectly fine with your file.
It just doesn't work with YellowPipe because it outputs to the page and you probably damage the output when the browser uses a different encoding. Using a decoding program or another webservice like MotoBit's Base64 Decoder to send the output to a file gives you a valid binary file, which you can rename to a WAV file (e.g. audio.wav) and listen to it.

Do that and you can listen to the message.
Then I don't know what the Applecore key could be used for. It could be that a secret message is embedded in the file by steganography. I assume that's the trick.


Does preventing password recycling increase or damage overall security?

Forced password resets make passwords worse - unless users are educated otherwise (which can be non-trivial, especially in the enterprise Windows space).

Password crackers know very well most of the common schemes that users use when faced with periodic forced reset (incrementing a number, "Spring2018!" to match the 90-day cycle, etc.). Password crackers have many tools to quickly exploit these patterns. "[Current season][current year]!" is literally one of the first passwords that pentesters and crackers will try. Because of this, forced resets are an understandable but ultimately misguided cure.

The true solution is a combination of user education (teaching users to use random passphrases), and improved technology (improved UX to provide immediate feedback about exactly why a proposed password is probably bad, and - crucially - suggested alternative strategies).

On the web-application side, the improved UX is possible today, but there are no good reference implementations that I'm aware of. (We should probably make one!) But your question is almost certainly driven by a corporate use case, since most websites don't force password rotation on a scheduled basis.

For Windows interactive login (the most common corporate use case), there are OS-level (passfilt.dll) constraints on how UX can be used to provide password-specific feedback to the user. So the Windows ecosystem is currently making it hard to help corporate users pick strong passwords (which is unfortunate, because NTLM passwords are one of the faster/easier hash formats to crack!)