Does the existence of two-factor recovery codes mean that my 2-factor code isn't completely random?

The backup codes, or scratch codes, are totally independent (at least in terms of operation) from your standard codes. TOTP is based on the time.
The scratch codes are rather based on an incremental counter.

The implementation details are probably provider dependent, but I think it's safe to assume that they use 2 different seeds. Maybe the underlying HMAC function changes as well, it's hard to tell.

On the number of digit, it all comes down to the choice of underlying HMAC and/or Truncation function. Why would the scratch code being longer than TOTP could be to ensure a sufficient level of security. The scratch code being fixed for potentially a long period, it makes sense for them to be longer. TOTP on the other hand requires less, because cracking the shorter code in the given time frame of availability is already hard enough, hence it provides additional flexibility to the user who has to type it manually.


Can phishing site URL shorten into numbers?

What you see is a SMS Short code.

Although IP address can be converted to decimal, the phone SMS application will not see it as an URL because "http" prefix is missing.

A smartphone SMS message box application usually does the following data highlights and link (parsing) for user conveniences.

URL with a http prefix. Let you click and open it from a browser
Phone number. Let you click and dial the number
Any number that looks like SMS short or long code. Let you click and open SMS compose box and use the code as the recipient.

Since every country SMS short code and long code length are vary, it is easier for developer simply parse a 5~8 digits number as short code. Although this is a bad idea when many services start sending Multi-factor authentication number to SMS.

A rogue SMS scammer can bait the user by asking them to reply to the short code with a blank response. When the gullible user response to it, the message will subscribe the user phone with a useless push message, which will charge the user $2~$10 from time to time (weekly/fortnight/month).  Such fraud/abuse is done using a method called Reverse SMS billing.


I know this tool, but I almost didn't use it, might worth a check:

https://appsec-labs.com/iNalyzer


Why should you clear your pasteboard when exiting your app?

The clipboard indeed cannot be considered a safe place, this for several reasons:

Malware accessing the clipboard content: in your question you focused on malware installed in your machine, however there could be transient malware (like a malicious Adobe Flash banner on a website you visited for instance...) which will not infect your computer when run, but just attempt to get the clipboard content at that time and send it to their home,
User wrong manipulation: A wrong manipulation could lead you to paste the wrong content at the wrong place. Usually without consequences, with sensitive data such wrong manipulation can still have heavy consequences,
People around the user: When the computer is left unattended and unlocked or if the user's attention is temporarily distracted, it is very quick for someone else to press a Ctrl-V then Ctrl-Z on his keyboard to quickly see his clipboard content without the user noticing.

While it is still better to avoid completely clipboard usage, when it is required the mitigation for such threat is to ensure that the sensitive data does not remain in the clipboard for too long: ideally it should just remain there enough time to be used and no longer.

In your question you suggest to clear the clipboard when the application exits. The efficiency of this greatly depends on the way the application is used: if this is the kind of application which is closed only at the end of the day such measure seems just ineffective.

An good example and inspirational source for this situation can be the password manager KeePass which proposes to handle this in two ways, depending on user's preferences:

To avoid completely clipboard usage, KeePass proposes what it calls Auto-Type: it will directly fill targeted fields by simulating the appropriate key presses. The advantage is that no data ever passes through the clipboard, however such behavior is more complex to implement and may not be fully compatible or portable (especially true since you mention a mobile application),
When using the clipboard to copy/paste passwords, KeePass can be configured to automatically clear the clipboard after a short amount of time. When copying a password, KeePass displays at the bottom of its main window a decreasing progress bar giving the user a visual feedback over the timeout progress, and once the timeout expires (15 or 30 seconds for instance) and if the clipboard still contains KeePass data then KeePass deletes the clipboard content (the user must not use one of those "clipboard history managers" for this to be really effective though).


Is there an example of a 'first' human error security breach?

Take a look at "Crime by Computer" by Donn B. Parker (Scribner, 1976;  ISBN-13: 978-0684155760).  In it, Mr. Parker describes several early computer crimes, including the first documented computer instance of the infamous "salami slicing" scheme that was parodied in the movie Office Space.

All of these crimes took place because of human error of some type or another; either through lack of oversight or carelessness.


Do any tracking networks or ad networks not use JavaScript and only track based on IP address? If yes, how can they be prevented?

It is most likely that some ad network uses this method. To be honest I don't know, but I'm going to answer your second question.

How can they be prevented?

1) Change your IP: You can use a vpn or a proxy or TOR to change your ip. But you have to trust your data with the VPN service provider or host.

2) Confuse them: You can confuse them with an automated bot that browses random pages of the sites that use the ad network, giving them false information about your interests.


Encryption before backing up to the Cloud

it seems that I have two choices using -

  Symmetric Key with AES and the like
  Asymmetric Key with RSA or GPG

You would probably not want to use asymmetric key cryptography directly because it is very slow compared to symmetric.

Without knowing more about how your data is structured it would be hard to say exactly what the best route is.

If your data is a bunch of files then just generating a random AES key and encrypting each file using a modern AES mode (e.g., GCM not ECB, at least something that uses a random IV) seems like it could work for you.

  The main questions that I have are -

  What is the more appropriate choice for my situation?

Symmetric.

  What is the right keysize for the choice? My understanding is the
  bigger the better. Since I don't need to access this data frequently
  I'm happy with the encryption/decryption taking longer.

256-bit symmetric key is likely quite big enough. e.g., AES 256.

  Any personal anecdotes or recommendations that you may have for me
  that will help me secure the data and balance security and
  usability?

Might be good to investigate whether the costs associated with your data security measures are reasonable in relation to the value of the data.

Update to address the comments:

If the single AES key is kept safe, then there no need for more than one as long as you use a modern AES mode that includes use of a random IV (and so that IV is different for each file).

If you are worried about keeping the single AES key safe, then you could use an alternative method (which is employed by certain ransomware as well). That method consists of: (1) Generate a single public/private key pair and keep the private key private; (2) generate a random AES key for each file; (3) Encrypt each file with its own random AES key; (4) Encrypt each random AES key with your single public key; (5) store the AES encrypted file and public-key-encrypted AES key together as one new file/blob. In this case you still have to worry about keeping the private key safe, but it is a little easier than protecting a single AES key that has to move around and exist on the actual machine doing the encryption (whereas with the asymmetric scheme only the public key has to move around).


Yes, booting from a USB stick on a system which has BIOS implemented means that the bootloader is on the USB stick. The start of the stick will have a bootable partition (containing a MBR) which the BIOS calls to load the OS.

Here's a question asking how to dump the BIOS.


Using free subdomains to circumvent web filtering systems

...Is there any way I can use the subdomains provided by a free DNS/subdomain provider (such as http://freedns.afraid.org) as fully featured domains to keep my site unblocked?

I assume you mean to have your own proxy at home and just have a static public host name for this proxy.

It depends what kind of block you are trying to circumvent and how you do it:

Running a real web proxy or a SOCKS proxy can easily detected because the traffic looks very typical and different from normal HTTP traffic. Corporate firewalls can often be configured to detect and block this kind of traffic. They block this kind of traffic not by target URL but just by the traffic pattern, so using another hostname does not help.
Running a forwarder which rewrites the URLs (e.g. rewrite http://example.org/foo to http://proxy.example.com/example.org/foo) is harder to detect. But it is a security risk because you effectively disable the protection by same origin policy if you are serving everything from the same domain. Even using a subdomain for each major domain (e.g. example.org.proxy.example.com/foo) would not be enough. And given enough traffic it might be detected because of unusual usage. But in this case it would be either by target host name or by IP address. In the first case using just another host name would work, in the second case the IP where you run the proxy service on is affected. A corporate network might also simply block all traffic to ISP for home users for security reasons (the IP ranges are known, so blocking is easy).
Having a local proxy instead which translates your requests and then forwards them to your external proxy might help be restoring protection by same origin policy. Apart from that the same problem with possible detection applies.

In any case:

If you tunnel only a few traffic inside a network with lots of other traffic the chance of detection is low, unless you use some easily detectable way like a HTTP proxy or SOCKS proxy.
If you try to circumvent some policy this way and you will be detected, than you have to face the consequences. It does not matter if this is a corporate policy, school policy or state policy, although the consequences might be different.


Openssl / OpenPGP file encryption - security advise

Both of these schemes seem a little overly complex. Try to keep it as simple as possible, because if you ever need to actually decrypt these files, you’re probably already having a bad day cause you’re recovering from a disaster.

I’d also encourage you to use asymmetric keys with gpg for a couple of reasons:

Every message (file) gets a new and random symmetric key
99% of the guidance on the internet about gpg is based on asymmetric keys, so when you’re having that bad day, it’s going to be easier to find help.

You can also encrypt a file for multiple private key recipients with GPG, and it just encrypts the same session key repeatedly using different public keys. This is great for eliminating the “bus factor of 1” on encrypted backup files.


Is the Struts2 token interceptor a viable way of protecting against CSRF?

If your application has CORS(Cross Origin Resource Sharing) enabled then yes, javascript code running in attacker page can make calls to your application, retrieve the token and send it in the next request which can result into cross site request forgery(CSRF).

However if CORS is disabled on your application then there is almost no way attacker can access your page and retrieve the tokens from it. CSRF attacks are usually done with the help of authenticated user by tricking them to click on some link running malicious code.

Struts token interceptor validate tokens once and then reset the token in Session object so that no one else can use the same token which could be due to CSRF attack or user trying to submit same request again(Multiple Form Sumission ).


Where is the most secure location to host an admin panel?

That's the old dilemma Security vs Usability, and only you can answer this question.  Having the admin panel on your PC only is surely safer, but having it on the server means that you can access it even when you're not at home.  And that other people can, too; unless you whitelist the access IPs, which however will also prevent you from accessing it from everywhere.

We can't really decide this for you apart from suggesting to protect the panel with a strong password if you decide to host it on the server.


Is installation id secure enough to authenticate device's user against a Web Service API?

What an Attacker can do is , in a rooted device, decompile your apk and understand what is being communicated with the API to do Authentication or Identify the user in your back end. They can re-engineer that communication process in any application(Desktop or another mobile platform).  Remember once some one installs your Android application in their devices , you do not have any control over that application.

Your solution would work in a controlled environment such as corporate network(Assuming you are installing the app only in known trusted devices). In public, I highly doubted your solution would work.

And according to the industry standards, it is not recommend to open up a public API (if your API is public) without any Authentication mechanism.


First and foremost,  STOP USING MD5!  It is a broken hash function,  and its been broken for many years.  Also you have to use an hmac,  calling md5 directly is vulnerable to a length extension attack.

Testing the ip address is problematic because this value can change if the user is behind a load balancer,  which is commonly used by universes and corporate offices.

The attacker will always have the user-agent, and this value is very easy to brute force.    Testing this value is in no way shape or form a "security measure".  Its a lot like having a variable is_attacker=no and making sure this value is "no",  which is A JOKE!  When I see a programmer doing this I smell blood,  if they actually think this helps improve security then they have likely made other mistakes.

Set your php session configurations as follows:

session.cookie_httponly = 1 (helps mitigate xss)
session.session.use_only_cookies = 1 (prevents session fixation)
session.entropy_file = "/dev/urandom" (better entropy source)
session.cookie_lifetime = 0  (smaller exploitation window for xss/csrf/clickjacking...)
session.cookie_secure = 1 (owasp a9 violations)


How can Process Hacker view my password manager's memory without administrative rights?

Per its documentation, Process Hacker actually launches a kernel mode driver, KProcessHacker. A kernel mode driver does have access to all memory.

Sources:

https://github.com/processhacker2/processhacker2#kprocesshacker

https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode


Stored XSS + PHP Backdoor + File upload vulnerability

Because when you do this <"script src="ATTACKING IP:PORT443/phpbackdoor.php"></script>
The file isn't executed server side at all instead it is executed by the victim browser and of course it doesn't work its a PHP file.The browser looks for javascript in that,for example try and PHP echo "VALID JAVASCRIPT" and it will get executed by the browser.You cant exploit like that.Instead if you can upload a PHP shell you would rather exploit it via simply going to the link https://example.com/shell.php or some other vulnerability like PHP file inclusion.

In short a shell uploaded on the server side wont get executed this way.


future of graphical password authentication

Well, you can break it down and look at it from a mathematical perspective.
A graphical image is really just a set of data being represented in a visual format for us humans. It's probably going to be salted and hashed to be kept safe on the authenticating machines, other than the fact that the input method might be a little different, (you might upload a pseudo-random bitmap for instance (which would need to be kept safe and never duplicated/transferred), or "draw" it in some sort of pre-organized format with enough entropy to be comparable to phrased passwords) it doesn't seem fundamentally different from your typical text-password scenario, other than the fact that people are probably far, far less likely to remember the intricate details of an image as opposed to a short sentence.


Aireplay-ng doesn't work properly on Ubuntu

Checklist to verify:

AppArmor - profile and logs, there can be interfering rules.
SELinux - same as above. Try disabling both as a dummy solution. If it still does not works - then first two options are no way in dealing problem. But I saw cases when they did
use ldd <command> and compare libs versions from Kali and Ubuntu. If Ubuntu - especially LTS - has an old ones, make a source compilation at Kali with full static binary - and use this binary on Ubuntu. It is the easiest way to fix this issue in Ububtu


Why does OpenID Connect use id token as a querystring parameter on logout?

Fragment encoding does indeed help with the web server logs scenarios, but I wouldn't go so far as saying that it's specifically used because of that.

Nonetheless, you pose an interesting question about including the ID token credentials in a GET request. I think a few things may allow this to be acceptable:

If the client is using the implicit flow, the specification also mandates the use of a nonce and additionally mentions that it should be used to prevent replay attacks. If this is the case, leaking the token after it's already been used should not lead to a significant problem as that token would not be accepted again by the client in order to start a new session.

  The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.

It's highly likely that the token itself might already be expired when the logout actually happens so reusing it on the client would not be possible. (the authorization server uses it only for context so it does not strictly requires a valid token)

Overall, I think you'll have secure implementations for which passing the token in that request will cause no additional harm and then have other implementations where it may prove to be a significant threat.

However, this trait does not apply only to that specific part of the specification, it's a general thing... authentication and authorization are complex subjects where small details make a big impact and where the landscape is always changing. That's why it's so dangerous to roll your own authentication systems.


Performant ways to identify potential SQL injection vulnerabilities in web applications

It's easier to use the tools that the attacker might try to figure out the holes. This is the lowest hanging fruit that you can do to ensure your application is safe.


Is there a cyber equivalent to the JTLS?

Are you familiar with the the DETER project?  It might be the sort of thing you are looking for.

A note of caution: I find that those new to the area sometimes have a lot of enthusiasm for the idea of "cyber testbeds", "cyber ranges", and the like, but personally, I am more skeptical.  Unless you already have substantial experience in the field, I think it is easy to overestimate the benefits of these things.  There is no silver bullet to security.


OpenSSL is an extremely widely used library. There are many legacy systems that only support old ciphers, and so the OpenSSL project is conservative in removing support for them, preferring to allow the user to configure allowed algorithms. This is in contrast to a library like NaCl, which is highly opinionated about algorithms.

As a side note, just because you have not heard of camellia does not make "no-name".


What TLS and SSL protocols should I have turned on

Enable all of the versions that can be enabled (preferably, TLS 1.0 and higher), and then let the order of preference to the server.

Since you're using Internet Explorer, go to the Internet advanced settings and enable the following according to your version:

Internet Explorer 6: Enable TLS 1.0
Internet Explorer 7: Nothing to do. TLS 1.0 is enabled by default.
Internet Explorer 8-10: TLS 1.0 is enabled by default. Enable TLS 1.1 and TLS 1.2
Internet Explorer 11: Nothing to do. TLS 1.0, 1.1, and 1.2 are enabled by default.


Can PHP files be dangerous without executing them?

In theory, the file could contain some (non-PHP) code that targets a vulnerability in the IDE you used to open the file (VSCode). This would require an exploitable vulnerability in the IDE itself though, and will probably be extremely obvious to anyone not using this specific IDE. This will make it extremely unlikely the file is dangerous.
As far as the actual PHP code goes, it can't do anything as long as it's not run by a PHP interpreter.


How to get TOTP password with hmac sha 512 as hashing function?

There is nice RFC describing the TOTP: RFC 6238, which mentions also usage of SHA-512. I did this in my implementation of OTP token in Javascript. But even the RFC has code examples in Java (same as freeOTP).

The algorithm is basically the same for all hashes. Basic idea is to take time (rounded down to 30 second boundary by default) and generate the HOTP of this value (instead of counter for HOTP).

HOTP later is basically HMAC with secret encoded in hexadecimal and with the counter (from above -- time for TOTP) padded to specific amount of digits. From the resulting hash, you take only specific part according to RFC.

For playing around, there are several web applications/jsfiddle that can generate you the TOTP on the fly, but they are certainly not for real-world usage.


Content hashes to help protect resources being fetched from a CDN

Update: There is more information on Subresource Integrity at  MDN, which (as of 12/12/16) shows support in Chrome 45+ and FireFox(Gecko) as of 43+

Update: There is a w3c draft called Subresource Integrity describing a feature like this.

It's already implemented in Chromium.

For example:

<script src="file.js" integrity="ni://sha256;BpfBw7ivV8q2jLiT13…"></script>

The basic approach is sound IMO, but there are a few details to take care of:

You should support several hashes on a single tag. The browser doesn't need to validate all of them, validating one collision resistant hash is enough.
Being able to specify the size seems useful to avoid some kind of DoS where your site is fed a huge resource
Unless you're using a tree-hash, you can't verify incomplete files. That's not an issue for 100kB javascript files, but it is for a 5 GB video. So support for tree hashes should be added later on.
I'd use algorithm identifiers matching NI - Naming Things with Hashes, and use urlsafe Base64 without padding
I'd specify SHA-256 as the standard algorithm every browser should support, but allow browsers to add other algorithms. SHA-256 is:

collision resistant at a 128 bit level
a NIST standard, implementations are widely available(unlike SHA-3)
performance isn't great, but still fast enough to keep up with typical network speeds on mobile devices.

IMO SHA-256 is the ideal choice for the default/mandatory algorithm.
You should support all embedded resources, CSS, images, videos etc. and not just scripts
One could consider using NI urls instead, but I prefer the attribute based approach here. An attribute is more flexible and doesn't require cooperation of the target host to implement. NI can only specify a single hash per url.
You could disable mixed content warnings for securely hashed content that was fetched via http
It's a great way to see if your cache is still valid. It's valid if and only if the hash matches. No need for rechecking, dates, etc. This also works if you downloaded the resource from a different url. For example if you already have jquery from google in your cache, you don't need to reload it from another url since the same hash guarantees[assuming collision resistance] that they'll be the same.
There are probably some issues related to authenticating http headers since those influence the interpretation of the resource. For example mime type and charset/encoding are such headers.

So an example might look like this:

<script src="http://example.cdn/jq/jquery-1.2.3.js"
     hash="sha-256:UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q; size:103457;
           other-hash: abc..." />


As you wrote, 1-5 can be achieved using KeePass + thumb drive.

As for point 6, It seems YubiKey already thought of that. You can use YubiKey or other HW token with KeePass using the OtpKeyProv plugin. However, I could not find a detailed explanation of how it works and it does not seem to me as very secure. I have a feeling it could be bypassed rather easily by a more advanced attacker.

There are plugins for KeePass that allow use of RSA keys, but I am not convinced they are usable with a HW token. Check (here, here and here)

The RSA key approach if implemented correctly would be very secure and would protect against the theft of the password vault from unlocked thumb drive.

For point 7, just pick a good USB drive, maybe the one recommended by Steven. But honestly, the thumb drive will never provide significant increase in security.

Final note: KeePass can be used on android, but I don't believe the plugins can be. So using 2FA would be at the cost of using it on Android.


Great question! I don't know that there are any hard-and-fast rules here, but you're definitely on the right track.

Here are some things that I look for when I'm looking at the descriptiveness of log and error messages, I generally think along these lines:

Error messages in internal log files are descriptive enough to help with debugging and live attack monitoring.

If there's PII (customer names, IP addresses, etc) in the internal logs, that's probably OK, but check compliance laws and make sure these logs are being properly protected.

Customer-facing error messages:

Visible pre-authentication should be static strings that are very generic. Ie do not echo back any dynamic content.
Visible only to a logged-in user: can be a little more flexible, for example it's not a vulnerability to tell a user their own name or their own account number, but as you point out, you want to keep this to a minimum because you're only one bug away from leaking info about other users, or leaking info about internal server state.

Under no circumstances should a customer-facing error message contain a stack trace.

Generally speaking, you're in a usability-vs-security tradeoff here. More descriptive error messages will help users figure out what they did wrong, and generally have an easier time using your product. That said, the more descriptive they are, the more you're asking for security issues.


What are the dangers of extending my PATH?

It is obviously dangerous to add a directory to the PATH where other and potential malicious users can write into, where others can modify existing binaries or where you have symlinks pointing to places which can be modified by others.  If instead everything is fully under your own control and only under your control then adding a directory to a PATH is less a problem. Of course, you can still screw up things by placing a binary there with the same name as a common binary but with a different behavior then an existing binary but this is shooting in your own foot.


What would the potential abuses be for an HTTP API that accepted raw SQL?

The potential for abuse obviously depends on the application.   Does this only face trusted employees on an intranet/VPN with privileged access?  Would these employees otherwise have read-only access to the DB, because there's a multitude of diverse queries they'll need to run on the data?  In that case, I can imagine allowing arbitrary raw SQL queries to be generated by the trusted user.

Or is this application out there facing any random attacker who may see your online store and is trying to do havoc?   In that case -- I strongly recommend you do not do this.  Take the time and go through the workflows and create the allowed parameterized queries that have permission to be run -- the user of the HTTP API only has permission to alter the parameters to these queries.

Parsing the SQL command for bad terms like UPDATE/DROP is a very bad idea.  People can get really clever bypassing these preventions (e.g., you bypass filters that remove <script> tags by using <scr<script>ipt> which then becomes <script>).  Similarly there may be valid reasons for some field to have the value "Update" in it.  There's possibilities of encoding issues/unicode normalization issues to bypass your filter.  E.g., an attacker sends DRO%C0%50 in the URL encoded string which gets past the filter that flags "DROP", but then when the bytes DRO\xc0P gets sent to the database its processed identical to being DROP allowing an attacker to drop the database.   (For more see this trick used in directory traversal attacks).

Having a read-only account is a better solution, but again you may not want an attacker to be able to access some private fields (e.g., CC #s, hashes of passwords, etc.).  Furthermore, it isn't hard to just create malicious SQL commands that are very CPU intensive and can be used to do a denial of service attacks on your database.

Letting an untrusted end-user write code (and an SQL command is code) is always an anti-pattern and should be avoided.  Yes, this will require more work initially coming up with the allowed parameterized queries, but its well worth it.

EDIT:

If your queries that are generated by your application are always fully trusted this is a different issue.  That is your application is generating pairs of parameterized queries like "SELECT name FROM users WHERE id = ?" sent to the database along with an array of untrusted user input -- ["1"] or in case of a failed SQL injection attack ["1 OR 1 = 1; DROP TABLE user; --"]).  Or potentially more problematically, but possibly safe you use some existing well known SQL injection sanitizing functions to sanitize your input to send something.  I personally wouldn't risk the second route, but a mature sanitizing functions may be able to do this.

Then all you need to do is use authenticated encryption (e.g., the messages are encrypted and MAC'd) between your application and the HTTPS API.  An IP address white list would be one reasonable way to accomplish this (in addition to say sending a password) all over TLS (and verifying identity of the other server hosting the API to prevent Man in the Middle attacks).


What are the risks associated with storing sensitive information inside of an encrypted container on a system without FDE?

I would say the biggest practical risk would be that a 'store my password' 'remember me' etc. option would be set. If this were done without FDE, an attacker could simply (with physical access) change the password for the account with the stored encryption key.

Any programs running on the system with sufficient privileges could take what they want regardless of FDE (e.g. a keylogger would just wait until you typed the encryption key/pw)

Applications running without sufficient privileges shouldn't be able to read memory outside of their own processes, but this relies on the OS and sandboxing not being exploitable. Also, temporarily decrypted data shouldn't be stored anywhere someone else could get to it (usually stays in memory). But that would depend on how the encryption software was written (use third-party-vetted software).

FDE is designed to stop offline (someone pulls your HDD out of the machine) attacks. If you're worried about the applications running on your system, that is not a system you should be using, or at least not using to handle sensitive data.


Can a time stamp protect a signature with the obsolete SHA1?

Collisions do not threaten existing signatures.   A collision means the attacker has the ability to create/modify both of the inputs to create colliding hashes.  The attacker obviously can't create or modify an existing document, so instead he or she must find a second pre-image, which is creating a single new input that has the same hash as the first input.  No researcher has made significant progress in breaking even reasonably old hashes like MD5 in this manner.


Why can't I MitM a Diffie-Hellman key exchange?

Diffie-Hellman is a key exchange protocol but does nothing about authentication.

There is a high-level, conceptual way to see that. In the world of computer networks and cryptography, all you can see, really, are zeros and ones sent over some wires. Entities can be distinguished from each other only by the zeros and ones that they can or cannot send. Thus, user "Bob" is really defined only by his ability to compute things that non-Bobs cannot compute. Since everybody can buy the same computers, Bob can be Bob only by his knowledge of some value that only Bob knows.

In the raw Diffie-Hellman exchange that you present, you talk to some entity that is supposed to generate a random secret value on-the-fly, and use that. Everybody can do such random generation. At no place in the protocol is there any operation that only a specific Bob can do. Thus, the protocol cannot achieve any kind of authentication -- you don't know who you are talking to. Without authentication, impersonation is feasible, and that includes simultaneous double impersonation, better known as Man-in-the-Middle. At best, raw Diffie-Hellman provides a weaker feature: though you do not know who you are talking to, you still know that you are talking to the same entity throughout the session.

A single cryptographic algorithm won't get you far; any significant communication protocol will assemble several algorithms so that some definite security characteristics are achieved. A prime example is SSL/TLS; another is SSH. In SSH, a Diffie-Hellman key exchange is used, but the server's public part (its gb mod p) is signed by the server. The client knows that it talks to the right server because the client remembers (from a previous initialization step) the server's public key (usually of type RSA or DSA); in the model explained above, the rightful servers is defined and distinguished from imitators by its knowledge of the signature private key corresponding to the public key remembered by the client. That signature provides the authentication; the Diffie-Hellman then produces a shared secret that will be used to encrypt and protect all the data exchanges for that connection (using some symmetric encryption and MAC algorithms).

Thus, while Diffie-Hellman does not do everything you need by itself, it still provides a useful feature, namely a key exchange, that you would not obtain from digital signatures, and that provides the temporary shared secret needed to encrypt the actually exchanged data.


Is it safe to use the Keccak Algorithm to create the Key for a Serpent cipher?

You don't create a key with a hash function. You create a key with randomness. Or, maybe, you derive a key from another secret value, using a Key Derivation Function.

A symmetric encryption algorithm is normally defined to accept "binary keys": any sequence of bits of some specific size is acceptable as a key value. When an encryption algorithm accepts a binary key, then any secure KDF which outputs such unbiased sequences of bits can be used to produce the key.

I suspect that you are trying to do password-based encryption: to derive a key from a password, and then use the key with a symmetric encryption algorithm. If that is the case, then do yourself a favour: use an existing protocol/format, don't try to design one yourself. These things are subtle. Nobody really knows how to make a secure protocol from the first try, or at least make sure that what they designed is secure (it cannot be tested). So the smart thing to do is to use something which has already been designed and heavily reviewed by lots of other people. I suggest OpenPGP.

Even better, if you use a standard format, then you may hope to use an already existing library which does all the job for you. It so happens that writing a secure implementation, even starting from a standard protocol, is also very hard. Code which is easiest to write properly is code which has already been written properly. In the case of OpenPGP, this points to GnuPG. Or BouncyCastle if you work with Java.


Is ist possible to emed a backdoor in a picture?

In theory, it is potentially possible to embed malicious code (e.g. a backdoor) in anything. However, for the code to be executed there must be some kind of vulnerability in the program that reads the image (e.g. Paint, Photoshop, Windows photo viewer) that makes it possible to fool the program into "accidentally" executing the code. Different types of buffer overflows are commonly used for this.

In practice this is not so easy, though. Since the program reading the image needs to be vulnerable, there is no silver bullet that will work everywhere. If you find a vulnerability, it will probably just work with a few particular versions of one particular program on one particular OS. And since vulnerabilities like this are (hopefully) patched as soon as they are discovered, you will either need to find a freash new vulnerability (a so called zero day) or only be able to attack victims who uses old, vulnerable software.

But still, this sort of thing happends in the wild. Here are two examples:

ImageTragick was the punny name of a vulnerability in ImageMagick, a software commonly used for processing user uploaded images on servers. It allowed remote code execution by sending SVG images that linked other images whose filenames contains shell commands.
If I am not mistaken, Stuxnet spread through a vulnerability in the code in Windows Explorer that processes the thumbnail images of USB drives. (I can not find a source for this, though.)

There is more on Google.


Chrome extension sends browsing information

For protecting your privacy, you could use another Open Source addon which protects you from the various tracking methods employed in today's method. The link to download is below :-

https://disconnect.me/

I am also currently using this addon, nice tool, save bandwidth, secures wifi, loads pages faster etc.

Also, the main feature that it completely eliminates the trackers so that the bandwidth is also saved. It also very nicely visualizes the blocking it is doing along with detailed information.

Furthermore, you can also protect your privacy by opening the web pages in the Icognito or the Private Browsing mode of your browser as by default in the Private Browsing mode, the addons are disabled and hence no tracking of your web page visiting atleast by the addons.


You have no control over what the VPS is logging. They may be logging all communications, or none. There's no way for you to control it and no way for you to know what they are doing. The VPS provider is subject to all laws for its locale including search warrants.

If you are looking for anonymity, consider Tor.


If you trust your login mechanism, and users can only change their emails while logged in, then simply:

Update the email address.
Notify the user on the website.
Send an email notification to the old email address about a change, including a link to report any problems.

Otherwise, use your Approach three, but without point 4. Also, in this case, send notification about the update to both email addresses.


Can the FBI or government agencies decrypt my hardrive and/or force me to give them the password?

The Electronic Frontier Foundation maintains an excellent FAQ on digital rights regarding search and seizure of computing devices. For your specific questions: (I'm going to assume US, because you reference FBI and NSA)

1. Can government agencies break disk encryption?

Without a warrant or probable cause, no. With a warrant, if your question is: "Can the encryption implemented by e.g., TrueCrypt be broken?" then the answer is that the TrueCrypt is believed to be secure. These things are difficult to prove, but for all intents and purposes, TrueCrypt is itself a secure system.

2. Can they force me to give them my password?

In the US, the 5th Amendment to the Constitution protects individuals from self-incrimination. A password to a computer containing incriminating information is treated as testimony so generally, no, they cannot force you to hand over a password. (Note that in the UK, this is not true - you can be jailed for refusing.) Per the linked EFF page, there are some exceptions (I believe that refusing to cooperate in an ongoing hostage negotiation can land you with an obstruction charge, but I Am Not A Lawyer), so this is one where you should contact an attorney.

3. Am I only protecting myself against a regular thief?

Per my answers above no, you are in fact protecting yourself, to at least some degree, against a law enforcement investigation.

In any case, "a regular thief" is generally a much more relevant threat actor than your  legal system.


Should password reset tokens be hashed when stored in a database?

Yes, you should hash password reset tokens, exactly for the reasons you mentioned.

But no, it's not quite as bad as unhashed passwords, because

reset tokens expire and not every user has an active one
users notice when their passwords are changed, but not when their passwords are cracked, and can thus take steps to limit the damage (change password and other sensitive data, etc).

Additionally, as users reuse passwords, an attacker can try a cracked passwords for other accounts, such as the users email, thus increasing the damage.


Risk around "Allow log on locally" for Domain Service Accounts

It is difficult to give specifics of attack paths with the limited information you have provided, however The documentation you cite states:

Vulnerability
Any account with the Allow log on locally user right can log on to the console of the device. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.

Applications are usually run using a Service account, as you pointed out in your question. These accounts usually have very restricted privileges that enable them to run the application and that is it. By enabling this feature, these accounts would be able to run an interactive shell (i.e. the Command Prompt). Using the command prompt, as stated, can allow a user to download and run malicious software.
There are a multitude of ways that a malicious actor can get a shell using an application, so without any specifics (other then you have a Windows Environment), it would be hard to comment on attack vectors.
One example could be: if the application in question has an upload feature, that then hosts the document on the web-server, an attacker could upload a malicious aspx page that gives them a shell (see example here). Then using this shell they could download and install malware, if the "Allow log on locally" permission is granted to that service account.


SSD is formatted twice and filled twice. Can i recover old deleted data?

Given the information that you have rewritten all ssd contents twice with true random data to the brim I'd say

No, you cannot recover any data from that disk.

This is the sane answer to give to people who lost data and e. g. show up in a data recovery shop.

If you want an academic answer weather or not it's possible at all then we're entering the hypothetical sphere of "given unlimited money and will - is it then possible?".
There are a lot of contributing factors (e. g. SSD Controller, state of dead cells, random data source, partition alignment, …).
But since you asked folks on the internet instead of physically shredding that disk I assume the disk holds no valuable information for any world power.

Please notice that the "Loose all data" option at your operating system installer does not perform a complete wipe of the disk.


From the KeePass documentation:

  File attachments are stored encrypted in the database (like all other database content).


Why does php password_hash() generate different hashes for the same input?

like the documentation of password_hash states, a unique salt is being calculated for each time it is called.

  It is strongly recommended that you do not generate your own salt for this function. It will create a secure salt automatically for you if you do not specify one.

(source: php manual - password_hash)

Additionally the used options of the hashing process are stored in the generated hash itself(salt,cost,algo) so the password_verify has all information's it needs to verify if a plaintext matches a hash without being able to decrypt it.

  Note that password_hash() returns the algorithm, cost and salt as part of the returned hash. Therefore, all information that's needed to verify the hash is included in it.

(source: enter link description here)

This also explains why the start of most hashes are identical.
For example depending on the cost and algo used your hashes might always start with something like $2y$10$ and from then on differ. This behavior can however change between different frameworks, algorithms or other factors, so take this only as a example of how the cost and algo can be saved in the resulted hash.


Why is end-to-end encryption still not default in mails?

It's not that hard, why isn't it standard for years?

Because that would not have solved the problem that PGP is trying to solve.

PGP is an end to end encryption, so if there is any way for the SMTP server to subvert the encryption, then the scheme fails.

In the case of the scheme you proposed, suppose Alice (alice@charlie.com) wants to send a private message to Bob (bob@dave.com). Using the scheme you proposed, Alice's mail client or Alice's SMTP server fetches Bob's public key by making TLS connection to dave.com. This is fine as long as dave.com are honest and actually return Bob's public key. But dave.com could have been configured by dave.com's operator to return a forged public key created by Eve, or Eve could hack into dave.com and set this up. Now Alice's mail client/mail server would happily accept Eve's certificate, thinking the public key is Bob's. In this model, the operator of dave.com can intercept any of Bob's emails.

Now, as long as dave.com is honest, this still protects against third party spoofing. Why don't we do this anyway if this protects at least against third party snooping? Mainly because SMTPS also provides the same level of protection, while also being much simpler. If MITM by the mail server operator is not your concern, you can already very well secure your emails by ensuring you both uses SMTPS.

Note that the difficulty of end to end encryption isn't about fetching public keys. Most email client that supports PGP also supports automatically fetching public keys from LDAP or HPKP. The difficulty of end to end encryption is verifying the public keys.

There is no known method of verifying public keys that is fully transparent to the users and fully secure. Web of Trust or Certificate Authority model comes closest, but Web of Trust comes with a lot of caveats and Certificate Authority model relies on a third party to do the verification.


How secure is the web-based file browser that comes with my NAS?

This is a great question and I think your reasoning is sound: Regular updates generally mean the software will have a better security posture. The flip side of that coin is that software that doesn't get regular updates is either perfect (not possible) or neglected. The later is much more likely. So your instincts are working :)

The reputation of the company or open source project providing the software in question is a big factor here as well. This is especially true if the software in question is proprietary as you'll have to trust that the provider knows what they're doing and has good security practices (which includes pushing out regular updates). A quick web search can help you here as you can search for known vulnerabilities in the software you're using.

Use caution though: just because vulnerabilities aren't publicly known doesn't mean there aren't any. This is often just a good indication that the product isn't widely used and that no one is attacking it and publishing their results. What you really want here is a history of vulnerabilities being disclosed and the product being updated in a timely manor (quickly).

Also be sure you know what interfaces you're exposing to the Internet. NAS boxes always support web UIs like you mention but they also have tons of interfaces for 'native' integration with Windows/OSX/Linux systems like CFIS, NFS etc. Exposing interfaces like these to the Internet has different implications ... like NFS having NO built-in authentication!

So to answer your question directly: I'd strongly discourage you from exposing the web UI of a home NAS device like the one you mention to the Internet. I would liken this to exposing the management interface on a server (like ILO / IPMI interfaces) to the Internet and recent history has shown that just a bit of poking can uncover a ton of problems in popular IPMI implementations: http://threatpost.com/ipmi-protocol-bmc-vulnerabilities-expose-thousands-of-servers-to-attack

As always you should balance the risks you're taking in proportion to the data you're protecting. If you don't have anything sensitive on this device and it all gets backed up elsewhere then the implications of a compromise are lower. You can just wipe it and restore if you need to (that is if you even notice that it's been compromised). On the other hand if you're putting sensitive data on this thing (business, personally identifiable information etc) then a compromise will be more damaging to you or your business.

In this situation, IMHO, the "right thing" to do is to set up a good VPN and require all access to the NAS go through the VPN. You can do this with an industrial strength VPN or something as simple as an SSH tunnel and proxy. Personally I do the later and it's sufficient for my needs but YMMV.

Hope this helps!


Is a 43 character GPG (symmetric) passphrase as secure as a 256-bit key?

There is in fact no difference in security between a 128-bit symmetric key and a 256-bit symmetric key. The reason is that security against brute force is relative to the technological means available to the attacker, and there is no way that the technology in the foreseeable future will allow a 128-bit exhaustive search to be performed with non-negligible chances of success.

By "foreseeable" here, I mean "within the next 30 years". Anybody who claims to be able to predict technological advances for longer times is either a time traveller or a filthy liar. Note in particular that it I claim that there will not be, in the next 30 years, a quantum computer that is large enough to run key tests on 128-bit AES and can do so for 264 steps -- the latter condition being very non-trivial. It is of course conceptually possible that mathematical advances will be found, that would simplify exhaustive search, but this is highly speculative and there is no real indication that a 256-bit AES key would resist such things better than a 128-bit AES key (in fact there are some esoteric attacks, called "related-key attacks", which fortunately do not apply to practical cases, and for which AES-256 is weaker than AES-128).

Since there is nothing stronger than non-breakable, one can say that AES-128 and AES-256 are equally good for security. We may even say that AES-128 is slightly preferable, since it is slightly faster (but it won't matter much).

That being said, in OpenPGP format, passphrases are turned into keys through a string-to-key transform. The recommended one (the "iterated and salted" transform) hashes a long concatenation of multiple repetitions of the passphrase and the salt. The total size of that which is hashed is configurable, but the point is that each passphrase try should cost a lot. This mechanically increases resistance to exhaustive search. For instance, if the iteration count is such that a passphrase-to-key transform costs as much as about one million AES invocations, then you only need 108 bits of entropy in the passphrase to reach 128-bit equivalent security. Of course, increased cost is increased cost: you do not get extra security for free.

The iterated-and-salted S2K uses an inner hash function which could be SHA-1 or even MD5, but it is not needy with regards to the cryptographic robustness of that underlying hash function. Even if it is the very broken MD5, and even so MD5 output is only 128 bits, the iterated-and-salted S2K is defined in such a way that it can still keep about all your passphrase entropy in the resulting key. Thus, if you have 256 bits or more of entropy in the S2K input (the passphrase), and you want a 256-bit output key, then that output key will have at least 255 bits of entropy.

(If you have exactly 256 bits of entropy in the input, you expect a theoretical 255.34 bits of entropy in the output.)

To sum up: there is no "gotcha" in the way the passphrase is turned into an encryption key, but even if there was, you would still get a security level that is not different, in any practical meaning of the term, to the theoretical "256-bit" level.


How effective have statistical methods been at breaking encryption?

Short version:

Yes, you're describing a known-ciphertext attack or statistical analysis
They are effective on old or deficient cryptosystems, and can be considered a standard and basic test kit for new cryptosystems
Their shortcomings are that modern cryptosystems are designed to thwart that particular attack, and the theory and practice of doing so is reasonably well understood at this time

Meandering version:

Language translation is dealing with a one-to-one or one-to-few transliteration, with rearrangements.  Each language has a finite dictionary with clear correlations, and each language has rules which define the structure into which words are put.  A translation engine relies upon these correlations.

This is totally dissimilar from encryption, where the goal is to mathematically break all such connections between cleartext and ciphertext.  What you describe worked well with WWII-era cryptosystems, but not today.  To quote Wikipedia (always dangerous, I know) "Every modern cipher attempts to provide protection against ciphertext-only attacks. The vetting process for a new cipher design standard usually takes many years and includes exhaustive testing of large quantities of ciphertext for any statistical departure from random noise.

This is not to say that statistical analysis isn't used, or that it can't succeed.  For example, some of the weaknesses in WEP enable statistical attacks to recover the plaintexts.  However, when it succeeds it's generally treated as a case where the encryption designer did something stupid rather than a cutting edge attack technique.

Edit - To reinforce that last sentence, let me quote from the conclusions of the WEP paper linked above: "[WEP]'s problems are a result of misunderstanding of some cryptographic primitives and therefore combining them in insecure ways."  Heh.


How safe is redirecting to another site?

/test and /Test are both hosted on example.com … so it's just a page redirect not a domain redirect … this is a non-issue.

People redirect like this all the time, for instance redirecting from HTTP to HTTPS is pretty much industry standard at this point.


Examples of software web clients (web browsers, IM clients, etc) written in "secure" / managed languages

The short answer is

All software is built on top of lower level software. Java is built on top of a Java Virtual Machine which is built on top of an operation system which is built on top of device firmware and your motherboard BIOS.
All software has bugs.

You can't say, I use Java so I am immune to buffer overflow attacks. Computers don't work like that because not matter what programming language you use, everything eventually ends up as instructions that execute on your CPU. There will always be an interface between your "safe" language and your "unsafe" CPU instructions.


What are the implications of using an "unsafe" DNSSEC algorithm like RSA/MD5?

This is still a matter of debate, see for example recently: https://www.ietf.org/mail-archive/web/dnsop/current/msg19820.html
(and https://www.ietf.org/mail-archive/web/dnsop/current/msg19868.html )
In the sense that there is no known public attack against DNSSEC that is based on MD5 weaknesses (or SHA1 for that matter).

However, the IETF has clearly said that MD5 should not be used anymore, see RFC6151 :

  MD5 is no longer acceptable where collision resistance is required
     such as digital signatures.  It is not urgent to stop using MD5 in
     other ways, such as HMAC-MD5; however, since MD5 must not be used for
     digital signatures, new protocol designs should not employ HMAC-MD5.

For example, since the DS record is an hash of the key, if an attacker can construct a new key with the same hash as an existing DNSKEY in the zone, he would be able to deliver falsified but correctly DNSSEC-signed records.


How Does The TPM Work With The CPU To Decrypt Data

There are a few concepts that are applicable to what you are asking about. The TPM is a "core root of trust" for reporting and storage. In the Trusted Computing Group (TCG--the organization that maintains the standard for the TPM) specification for PC Client Implementation for BIOS, the BIOS bootstrap code is the core root of trust for measurement.

The BIOS bootstrap code measures itself (generally, by means of a cryptographic hash), and then the rest of the BIOS code and configuration. This measurement chain is carried through to the boot sector of the hard drive (or whatever other boot device is used). As these measurements are taken, they are extended into Platform Configuration Registers (PCRs) held in the TPM. With the exception of that BIOS bootstrap code, all code is measured, and the PCRs are irreversibly extended (until next boot), before the code is allowed to run. This system should ensure that any modification for the code running on the system should be reflected in a different set of PCR values.

The TPM also secure's keys and key material. When these keys are secured by the TPM, it can be specified that they should not be made available unless the PCRs have some specified set of values. This key material can be used by drive encryption software. There are a handful of different drive encryption systems that have been engineered to use the TPM in this way, and they all operate slightly differently. You'll need to investigate those systems to see how they use the key or key material from the TPM for drive encryption.

As for documentation, you can check out the TPM specification and the PC Client specification from the TCG. Microsoft uses Bitlocker. You can also check out this system, which uses LUKS, the TPM, and TrustedGrub for Linux drive encryption.


Can a web server be secured with just a firewall?

It isn't a game of magic ports used by hackers.  If there isn't a service running on the port, it's unlikely in the extreme to result in a compromise, but it's nonetheless a good idea to use a strong firewall, especially on windows where lots and lots of services are running by default.

That said, if someone is going to compromise your web server, they will do so using the software you are letting them access (both your http daemon and any CGI applications you're using).  So, the answer is no.

You haven't given a lot of detail about what this project is, but if it's a CGI application of some kind, the most important thing you can do is code it carefully to avoid vulnerabilities.  If someone can inject shellcode into it and pop a shell, they can usually access things you didn't intend.

Webserver misconfiguration can also be a problem, if you allow things like directory traversal and indexes; these can be used by attackers to "trick" the web server into serving up things you didn't plan on.

If you allow users to upload files, be careful as well; they might upload scripts you'll accidentally run, or upload malware which you'd then be serving.

Sometimes functionality you intend on can be abused too; forced browsing (as with wordpress trackbacks) and email sending can both be abused by attackers to hide their activities behind you.

Some things you can do are:

Use a separate user for your web application.  In IIS, set the application pool user in the CGI settings, and the user used for anonymous authentication in the authentication settings.  Make a specific user for this and limit their privileges to the minimum necessary.
Try to think of all the things that can be done with any application you implement and make available, rather than just the things you intended it to do.


Exposing a version number through the assets urls

While exposing specific version numbers is considered a bad practice and is not recommended, in this case I do not really see an issue.

It is likely that the version is also displayed as a comment in the CSS file (and often also in JS files). It's quite easy to identify the version for such files (not 100% reliable but 99 out of a 100 times it will work)

As a security consultant, I would be more interested in your update policy:

How often do you check for updates on externally[1] used dependencies (CSS / JS)
How often do you apply these updates?
What's the process you execute before using these updates in production systems.

[1] I am not stating that you load these resources externally, just stating that it's a CSS file that is not created by you or your company.

As a side note: If this is considered the worst problem you have with your application, you've done quite well.


Are there any reasonable TrueCrypt forks?

The main obstacle of a TrueCrypt fork is the non-standard TrueCrypt license.

While the intention of the authors seemed to be to write a share-alike license similar in spirit to the GPL, the license has a few quite unorthodox passages which can be interpreted in a way which puts unreasonable conditions on a fork. These conditions prevented the Open Source Initiative from recognizing it as an open-source license. A fork of the TrueCrypt project might not be legally possible without the permission of the original TrueCrypt authors, who prefer to remain anonymous for now.

Nevertheless, there is a team in Switzerland which promised to continue working on TrueCrypt under the name TrueCryptNext.

Edit: Now there is the company Sirrix from Germany which wants to make a TrueCrypt fork called TrustedDisk. To get rid of the complicated TrueCrypt license, they plan to reimplement those parts with questionable license conditions and release the software dual-licensed under both an common open source license and a commercial version (German news story).


Firefox accuses of malware, but virustotal have 0 matches

Firefox is not an anti-malware scanner, it uses a blacklist which it updates from various feeds e.g. Google safe browsing, phishtank, etc.

Since Firefox is pretty new in such a field, they tend to be "excessively paranoid", e.g. based on many bad URL and derive the blocking result, as mentioned by @Steffen Ullrich.  As a Firefox user, you can help by clicking the button on the warning screen. When there are enough clicks, hopefully, Firefox will notice it and unblock it.

Unlike malicious file detection, URL blacklisting is never easy to do it "correctly", due to the dynamic nature.


How can I extract the encrypted master key from LUKS header?

It looks like this is what you want. It creates a copy of the header, without making any assumptions about the header size.

# cryptsetup luksHeaderBackup /dev/sda5 --header-backup-file /tmp/luks-header

But I'm not sure if I 100% understand your question. Are you asking how to extract the LUKS header including the master key, or just the encrypted master key and nothing else?


I think you want Filesystem Slack. As Xaqron says, you will need a hex editor that can open drives, because opening up a file will only help you with File Slack, not Filesystem Slack.

Preferably you should use a Hex editor that shows the ASCII characters at the same time as the hex data.

Manual review using Hex editor

Once you have such an editor, you have to find out what you are looking for?

Let's imagine that you are looking for a Word document that has been erased. The best way to start is to look at a Word document with a Hex Editor, and then find some kind of code at the very beginning of the file, which you will likely see on all word documents.

Once you find such code, you will be able to search for this in the slack space.

One problem you will find is that opening a drive directly will show you all data, both Allocated and Slack. Unfortunately, it is difficult for a human to distinguish which is which. For example, if there are some real Word documents, as well as deleted ones, then how could you tell the difference? This would be very difficult.

Perhaps you will instead need to search for key words or phrases that you are interested in. Keep in mind, that some documents will encode the text differently. Again, you should compare what non-deleted files look like before searching this in Slack space.

The same principals apply for any document type, not just Word. For example Image files often have a few bytes at the beginning that you can use to tell what type of file it was. Unfortunately, images are heavily encoded so you cannot search their contents.

Some files like txt do not have such identification, but are also very light on the encoding, so they are easier to find in slack space.

Keep in mind that Slack Space will often be a mess, with partially overwritten or expired chunks of files. De-fragmentation processes or re-allocation to other files can introduce gaps in what you are able to recover.

Tools

A couple more things come to mind.

There may be a specialized hex editor or other tool available that will highlight and search Slack Space separately from Allocated Space. I don't know if there is one, but it seems like there would be. This would really help your manual review process.
There are applications designed to identify and restore files out of Slack Space. These automated tools (restore deleted files) are readily available and are the easiest way to get something productive done.


There is one solution to this which does not require that you include other dependencies like Argon2. You can implement the algorithm used by OpenPGP, called String-to-Key, or S2K. This algorithm works by feeding the repeating password and salt to a hash function. The password and salt are repeated enough that it takes the hash function a non-negligible amount of time to process it. This is such a simple slow KDF that it can even be done using standard Linux utilities (in this example with SHA-256):

yes "$pass$salt" | head -c 50M | sha256sum

If you are ever able to bring in your own dependencies, I highly recommend listening to Future Security whose excellent answer lists superior alternatives to both S2K and your custom scheme.


Checking a salted hash against known password?

SHA-512 and Whirlpool are two distinct hash functions, so one has to assume that you are using one of them, not both. There is no hash function called "sha512whirlpool"; this would be a most unholy hybrid.

Cryptographic hash functions do not use salts. Password hashing functions are complicated constructions that may be built with cryptographic hash functions, or other elements. mkpasswd is a command-line interface for the C library function crypt() (which deals with password hashing and not at all with encryption, despite its name). On Linux systems, crypt() supports a number of password hashing constructions, one of them using SHA-512 repeatedly, mixing in the password and the salt at various steps. This is in no way the only password hashing construction from an underlying hash function, so there is no guarantee that the examples you have at hand really used that function.

Password hashing constructions tend to work over bytes, for both the salt and the password. But humans like to read characters. There is thus some translation between the two, and, there again, there is no universal convention. Your salts, like "ecb2796f-e69d-4ad6-858f-832170b00b5c", are reminiscent of the traditional string encoding of UUID. An UUID is a 128-bit identifier, i.e. a sequence of 16 bytes, but the character representation uses hexadecimal with a few extra dashes, for a total of 36 characters. When you invoke mkpasswd, that tool tries to convert the provided salt string not by interpreting it as an UUID in hexadecimal-with-dashes, but by mapping each character to its ASCII code, thus transforming the 36-character string into a 36-byte salt. It then chastises you for providing a 36-byte salt, while the internal function expects a salt of legnth 8 to 16 bytes only.

Since the mkpasswd command-line tool expects the salt as a "string", passing arbitrary bytes may be complicated in case you want to provide bytes that do not map to printable characters. The crypt() function itself expects a salt that consists of non-zero bytes. You may have to resort to programming...


I wanted to add a comment, but I'm new here, not enough rep...

About the long-lived refresh token, you shouldn't get on with your PKCE based SPA. It should be access token and id token only (for bearer) or possibly id token only (for JWT stateless).
By definition both should have a short life with no refresh possibility. Instead you should use the iframe defined in the spec of openid to "refresh" the access id tokens without the use of a refresh token.

Here's an example of an angular lib that implements the iframe logic: https://manfredsteyer.github.io/angular-oauth2-oidc/docs/additional-documentation/refreshing-a-token.html
Look at the implicit flow, silent refresh logic.

If you really want to have a refresh token with a PKCE on SPA, the requirements you should meet are here: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 section 4.12. Be sure that the refresh token logic is correctly implemented by the auth server.


Appropriate length and slow, unsalted cryptographic hash function for random codes?

First of all, let us assume the code is in the form of XXXX-XXXX-XXXX-XXXX. Four groups of four alphanumeric symbols, kept apart by dashes for easier readability, is something that is not too bothersome for a user to type in. I will assume that the code will have to be typed in and can't otherwise be submitted to the application (e.g. an URL, copy/paste, etc.), because in such cases, there really is no reason not to use very long, completely random tokens instead.
Next, let's have a look at the structure. I said "alphanumeric" before, but there are some characters which make sense to exclude, such as 0O1IS5 and perhaps others. You don't want a user to mistake an O for a 0, for example. Sure, it may seem obvious to you, but not for everyone - so for the sake of usability, drop all ambiguous characters.
That leaves us with 16 characters and a 30 character alphabet, meaning we have 30^16 possible keys, or ~78 bits of security. In terms of a randomly generated key that a user should type, that's not bad. (By comparison, using 36 characters gives you ~82 bits). So that alone makes online brute-force attacks infeasible.
However, you also want to protect against offline brute-force attacks, in case someone steals the keys. To do that, you should store the first four characters in plain as an identifier. That allows you to generate 810,000 different keys at once, while still leaving ~58 bits of entropy for the secret part.
For the hashing algorithm, you have two sensible choices: bcrypt and Argon2id
bcrypt is the "you can't mess it up"-choice. If you have a good cryptographic library, you should have a function like password_hash(string password) and password_verify(Hash hash, string password) - or similar. These will take all the trouble of using good parameters for bcrypt from you.
Argon2id is the "better if you know what you are doing"-choice. It offers better resistance against offline-brute force attacks, but depends on the correct configuration. You can read about it in more detail, but if you're not already familiar with it, I would suggest using bcrypt instead.
By using these as designed, you will get a hash from a strong key-derivation function, designed to make offline brute-force attacks infeasible. It also makes pre-computation attacks infeasible, in which attackers calculate the hashes beforehand and then compare - since this would take ~22 Yotta-Byte of storage (~22,000,000,000,000 TB), that's not feasible.
To summarize

Generate four characters to "identify" the code and make sure that's unique
Hash the entire code using either bcrypt or Argon2id
Verify the entered code with the stored hash


You can prevent Ghostery from selling your data by opting out of the Ghost Rank feature. The feature is opt-in, so if you didn't already opt in there is nothing you need to do. It is then safe for you to use.

Using a clone of Ghostery which is identical in every aspect except not having the Ghost Rank feature would make no practical difference from running Ghostery without opting in to Ghost Rank. If your intention is to actively punish Ghostery for their evil data trading by boycotting them, then you will achieve nothing. They already gain nothing from you commercially when you run Ghostery with Ghost Rank disabled. If anything you help them by uninstalling Ghostery because you no longer consume any of their resources.

But if you are really looking for an alternative option: the classical method is to edit your operating systems hosts file and forward the hostnames of known trackers and advertising networks to 0.0.0.0. There are recommended blocklists available which you can find with a websearch (I can't vouch for their quality, so I won't recommend any specific ones). The advantage is that it doesn't just block advertisements in one web browser, but in all web browsers you have installed and in any other applications which might access these hosts for whatever reason. The drawback is that you will have to maintain your blocklist manually.


What kinds of security risks do wifi enabled laundry machines and other internet of things appliances pose?

There's at least two security concepts here that you're concerned about: vulnerability and availability.
First, vulnerability. Anything that is network-connected is theoretically network-exploitable. So adding another device to your network does increase your risk. A NAT firewall at your home network's boundary would prevent incoming connections. But there are at least two more attack vectors. If someone is able to get onto your WiFi and join your network, then they can talk directly to your washing machine. Or the app you use to talk to the washing machine may itself be vulnerable. If an attacker has the tools to install malware on your washing machine then you could be contributing to a bot net, which could create a lot of malicious network traffic.
Second, availability. You specifically asked about a requirement for online access in order for the appliance to work. I can't find any situation yet where that happens. But it definitely happens with video games. So it's an option that companies are aware of. This situation is related to digital rights management (DRM). In my opinion, the bigger availability problem is if the device relies on an external server in order to function, and then the company drops support and turns off the server, making the appliance useless. Amazon has done this to a couple different devices although none of them are comparable to a home appliance like a washing machine.
A final possibility that you didn't mention was privacy. Is your appliance collecting data about you and sending that data back out? Will your appliance start showing you ads every time you want to wash something?
I do own an oven that is WiFi-enabled. It is not connected to my network.


Do stored procedures prevent SQL Injection in PostgreSQL?

In short - no, stored procedures does not prevent from SQL Injection. It depends on how you do handle dynamic SQL inside stored procedure.

For more complete answer, check what is posted here: https://stackoverflow.com/questions/627918/am-i-safe-against-sql-injection


A virtual machine is an operating system installed on a virtualization software such as VirtualBox and VMware Player. It emulates the existing hardware of the host machine on which it runs. This means a software running on a virtual machine will "think" it is running on a "normal" computer resources. You can do on it all what you do on a usual computer with a running computer system. It is used for testing applications, emulating networks and even testing applications for the presence of malware as SpyProxy is functionning.
COMODO and other virtual desktops are a typical cases of a virtual machine. For example, if you run a browser on a virtual desktop, you won't have any cookies saved unlike it on a virtual machine. However, it is more intended to browse the internet against web malware attacks.
While they are both virtualization concepts (a computer inside a computer), a virtual desktop runs only ONE virtual machine, whereas you can install and run several virtual machines on a virtualization system such as VirtualBox.


Can a Router Cable/Wire be Affected or Infected by Malware?

No for current network cables this won't be the case.

That said don't rule this out on future cables which contain tiny microchips like some of the Apple charging cables which have authenticator chips hidden in them. As time goes on these will have more features and more potential to be used in attacks. For now though you have nothing at all to worry about.

The following is a teardown of an Apple authenticator chip from a 3rd party adapter, the Apple OEM ones have a smaller form-factor but essentially the same chip. Note how small the actual chip is in the end of the video.

https://www.youtube.com/watch?v=r7ZQb17p-sU


Is there any chance PHP developers themselves implement backdoors in PHP core?

Backdoor are uncovered on a fairly regular basis.   This is by no means something unique to PHP, and can happen for a verity of reasons.  Open source projects are not totally immune as code can be quite underhanded, however this is not something that just affects open source projects

For example,  Horde (php) was hacked and the attacker introduced a backdoor,  but the same thing happened to VSFTP (C/C++).  Sometimes the software vendor will intentionally place a backdoor in their own code.  This is believed to have happened to RuggedCom's SCADA Systems,  which is closed source.

Worms can contain a backdoor.  For example MyDoom was an email worm that spread and opened a port which allowed code execution.  Later a worm called DoomJuice spread using MyDoom's backdoor.  Also verities of the PhatBot/AgoBot family of IRC bots spread piggy backing on MyDoom's backdoor allowing any teenager with a C++ compiler to take advantage of it.

It is easy to carelessly leave out a sanitation routine,  who's to say its a backdoor?


NSA was undergoing a transformation on the subject question during the timeframe you are questioning.

In the previous two decades through the mid 90s NSA advocated for no strong privately controlled public encryption.  This position surfaced with their clash with MIT over the work of the famed RSA crew Ron Rivest, Adi Shamir, and Leonard Adleman resulting in the rushed publishing of same in 1976.  Federal funding for MIT was threatened during that dust up.  That position continued through the next 15 years highlighted by the flare up with Phil Zimmermann and PGP which almost landed him in prison.  By 1993 NSA was advocating the ‘Clipper Chip’ solution (using Skipjack) which created a back door key escrow for all public encryption.  The pushback against the concept was great from both academia and the common computer enthusiast.   That sets the stage for the period you question.

Times were changing as the Cold War ended, BBS-based personal computing was replaced by web browsing based on the Netscape browser with its PKI SSL solution, and with those changing times so changed NSA.  By July 2000 NSA had gone so far as to partner with Network Associates, the owners of Zimmerman’s PGP at that point, to create a free open source operating system – SELinux.  NSA by that point embraced publically available encryption as we know it today and provided hardening recommendations using same.  You can find specifics at http://www.nsa.gov/ia/guidance/security_configuration_guides/archived_guides.shtml .   Keep in mind that NSA was actually just joining the public using commercial standards of the day in the period you are questioning.


Security of a Windows XP system after April 8th when running the latest Firefox or Chrome

It's a risk.  XP has had enough holes over the years that it's hard to imagine there aren't some un-found holes in what remains.

I'd recommend getting off XP if possible.  If not, at least keep your ear to the ground.  If a researcher finds more vulnerabilities that Microsoft is now unwilling to fix, you can bet they're going to hit the tech news media.

Tell your client it's time to consider changing, and to save a few dollars for a new system.  You can also consider alternative operating systems that won't require a new computer:  an installation of linux should be able to run on anything that currently runs XP.  This might be a fine choice for someone who isn't dependent on Windows native apps.


Reflected XSS via JSON executed with Burp, but how to do it in realistic conditions?

The proposed reflective XSS vulnerability is completely and totally unexploitable by modern browsers due to the following content-type:

Content-Type: application/json;charset=UTF-8

The content-type needs to be HTML, or a missing content type would do the trick. Having a content-type application/json or plain/text are both strong mitigations against XSS.

Content sniffing can be used by old browsers to execute JavaScript despite the defined content-type. As an attacker, if the target browser still uses content sniffing, then the browser is also vulnerable to worse bugs, like drive-by remote code execution.

As @Jeroen pointed out, this is an insecure input validation issue, and although it might not be vulnerable to reflective XSS, it could lead to other problems such as 2nd order code injections, and persistent XSS.


securely destroying data on an external hard drive

If you're just trying to securely wipe the slack space of the drive, i.e. the sectors that are free after file deletion, there are a few easy ways to do it.

On Windows, you can use cipher /W:C:\ (replace C for the drive letter you're targeting) to perform secure deletion of the free sectors. This should work fine for HDDs, and even implements (arguably pointless) multi-pass wiping.

For Linux, you can use the secure-delete tool, which should be available from your package repository. There's an answer on SuperUser that covers this. Again, this supports multi-pass wiping, but it's unnecessary.

Keep in mind that if your external drive is running over USB it will be slow. If possible, remove it and hook it up to the computer directly, e.g. via SATA. This will massively increase the disk throughput.

If the external drive is an SSD, things get more complicated. SSDs are built out of special flash cells which have limited write capacity; once you write to them a few million times they'll burn out. In order to make the lifespan of these devices more useful, two main techniques are used. The first is wear levelling, which involves distributing the writes across different cells, and storing a map to these fragmented instances of data. This helps solve cases where a single file is written to frequently, which would normally result in the same cell being written over and over, causing premature burnout. Unfortunately this also means that you can't guarantee that a file write will actually overwrite the same physical cell, so you can't guarantee that you've wiped the data. The other technique involves providing redundant cells which can be used to help increase the lifespan of the disk. When a cell is detected to be faulty (usually through burnout) it is re-mapped to a redundant cell. Unfortunately this means that old data might be left behind on the old cell, which also leads to leakage.

In order to provide some form of secure deletion method on SSDs that works despite the life extension mechanisms, without resorting to extensive erasure operations, manufacturers encrypt all data that goes onto the sectors with a strong block cipher such as AES. The key for the encrypted data is stored on the device, and the encryption / decryption is entirely transparent to the operating system. When the user wishes to securely wipe the device, the operating system can send a special command to the drive which causes it to generate a new key and overwrite the old one. This renders all data on the device, redundant or not, entirely unreadable, without ever writing over the cells. Unfortunately this results in deleting everything from the disk, including all partitions. There's no way to do a partial secure delete - you'd have to copy the files you want to keep over to another disk, then wipe it, then bring the files back over.

Actually doing this secure deletion operation is usually dependant on the device, but most manufacturers provide tools or instructions on how to do it.


You can do this by making a customized active response. This will require you to write a script which can add IPs to your remote firewall. I suggest reading up on the linked documents as they explain this quite well.


Does an email header/source contain sensitive information?

It depends on what you classify as sensitive. The following is a (not comprehensive) list of things that could be contained in an email header that an attacker could make use of.

If you consider any of the following sensitive the answer is yes.

Sender and recipient email addresses
Server names, which could reveal FQDN of your internal domain
Your organisations public IP address
Information on servers that have handled the email
TLS/SSL info & what ciphers you use (or don’t use)
Banner information
Email gateway details
What Anti-Virus you use to scan email


should I give the csrf token a descriptive name?

Call it that if you want - it doesn't affect the security of your system in any way.

At the end of the day, you can't protect against everything. If social engineering is involved, then the scammer could simply devise a reason for the user to give them the account password directly.

There are also other attacks that are difficult to defend against where users are involved, such as Self-XSS. This is where a scammer convinces a user to enter some JavaScript code into the browser dev tools with the promise of hacking somebody else's account.

A better approach to both these issues is to educate your users.


Cannot figure out how to bypass this function for lfi

Usually it will be the path, followed by null byte in order to terminate the string when the C code runs that actually retrieves the file:

http://example.com/challenge27/?page=../../../../etc/passwd%00

Note that null byte characters don't work in up-to-date versions of PHP.

The other challenge is to get .. past the filter.

Try these to see if they can bypass this checking:

Try using 16-bit Unicode encoding (. = %u002e).
Try double URL encoding (. = %252e).
Try overlong UTF-8 Unicode encoding (. can be %c0%2e, %e0%40%ae,
%c0ae)


GDPR Deletion Request Tracking Paradox - Suppression Lists

It is exactly the right thing to have a deletion request management system. In fact, given the importance of this function, the timeframes for response, the workflows to coordinate, it is almost certainly necessary.

GDPR does not prevent companies from storing personal details of their users/customers/etc for legitimate purposes. Instead it is intended to generate more thoughtful practices around the management lifecycle typically associated with this sensitive data.

For instance, what teams in companies do to record interactions with different flavors of users is track relevant and often personal details in whatever workflow tool the particular team happens to prefer. Maybe this is Salesforce, or JIRA, or email. Whatever.

This careless sprinkling of personal details around team-specific workflow infrastructure is one of the anti-practices a successful GDPR implementation will ideally deprecate.

So a deletion request management system needs store personal information that is used to match in other systems. It needs to be sufficient to identify the person requesting the deletion. That data can be retained for the duration of its legitimate need. When that need has expired- the deletion workflow is completed- this system is no different from any other. Personal details get deleted from the deletion request management system as well. (The exact policies and timing around this are of course decided by the legal team).

In terms of practices, the likely common practice with databases is scrubbing. IDs of records with scrubbed fields need to be retained, both for future validation and also to support the scrubbing process being applied following a restore of production data from backup.

When it comes to matching, one nit- my understanding as a non-lawyer is that what is considered to be personal information is not just identifying information like first and last name. Personal attributes that may not be identifying but are nevertheless unique and characterizing of a person are also subject to deletion/scrubbing.

Using hashes to efficiently match fields across systems may help, but with names, there are numerous spelling and other variations. Doing this sort of matching is its own data management practice that companies that have had to consolidate customer databases are likely familiar with.


How does an insecure RNG affect cryptography, and how do I measure the corresponding loss of security?

It all depends on where the RNG is being used.  A good post with links to good reads.

Encryption: IV Generation
Encryption is effected because the entire point of an Initialization Vector is to provide more randomness into the crypt context without rekeying.

Encryption: Key Generation
I feel like this should be obvious, if your key is predictable in any way then what's the point in encryption?  Any public key cryptography used to protect the key is invalidated because now the key can be derived, and communications decrypted.

Public/Private Key Generation
Weak key generation for asymmetric cryptography is extremely bad.  If you can derive a private key it can be used to impersonate people or servers.  Signed data with that certificate is now distrusted.  Any session keys exchanged with its public key to encrypt data can now be exposed.

Integrity Hashes
These can be indirectly effected if you're using an HMAC, this goes back to bad key derivation.  If the integrity key can be derived, then an attacker can insert data into a stream and it will be accepted on the other side as legit data.

Now performing attacks against these weaknesses aren't always the easiest, but they're all doable.  It depends on the protocol that's being used, how much other data is needed, etc.  In a protocol like SSL/TLS you need data from both sides, plus the key shared in order to derive all keys.  I hope this answers your question, I'd be happy to answer in more detail if you'd like.

Examples of when RNGs went wrong.


Hydra from Kali Linux + Tamper http post form syntax of the failure login attempt

Manual:

-v -V: be verbose
-L: user list
-P: password list
-l: username
-p: password
-s: server + port
“1:2:3:4”: 1=page, 2=body content, 3=failure (F=) or success (S=) message, 4: H= headers can be specified (optional). In headers, you do not have to escape the colon.

So, what you should do is add something next to the S= you have there. That something should be a word that appears in the page to which your site is redirecting after successful login (e.g. success, welcome, etc.). Something like this:

  hydra -l tech15 -P fakelist.txt -vV www.mysite.com http-post-form
  "/members-login.php=:user^USER^&pass=^PASS^:S=Welcome"

Of course, if you have a specific failure page (e.g. "login failed"), you could just replace the S= with F= and add "F=failed"


What attacks use enabled Apache's PATH_INFO?

PATH_INFO is an attacker controlled variable and there for can be the source of tainted data.  This variable should never be trusted and a web application must be vary careful not to use this when manipulating files (directory traversal)  or printed to the browser (XSS).

An example of an attacker controlling this variable can be seen with this url:

https://cgi.ccs.neu.edu/home/cgiadmin/examples/phpinfo.php/ATTACK

In terms of non-injection attacks,  I used this property of PATH_INFO to bypass Wordpress's Access Control System.  They where foolish enough to look for the word "admin" in the PATH_INFO variable to check if you where an administrator.


Login attempt password logging and obfuscation

I can't see any security claims to the application to store the clients inputs. Also, the "ciphertext" seems to be reversible (instead of a hash). It's a bad practice.


"Whatsapp Web is open in another computer or browser" - What should I do?

Open Whatsapp in your handset.

Go to Options named "Whatsapp Web", Click on "Logout from all computers" & then try to login again.


Is this logic security / performance wise or not?

This is a bad design (or no design at all for that matter).

You should model your tables like you create classes in object oriented programming : each class / table represent a concept, so you should have a User table and some permissions on other tables for each user.

Merise is a great method to design database (and much more but it's mainly used to design databases nowadays).
I'm afraid it's a french cultural exception as no other country seems to use it, but if you can find resources in your language it would be of great help with your designs.


Passwordless authentication - how and when to invalidate a login code

Instead of invalidating the login code when the link is clicked, have a script on the page that runs and makes a request to your server to invalidate the code.  This will only be effective if the "mail scanner" just visits the page and doesn't run any scripts on it.

You should also invalidate the code after a period of time (your second option), because if the user is running a browser with scripts disabled the code will not be invalidated by this method.  The timeout serves as a backup if this is the case.

If you find that whatever "mail scanner" your users have is running scripts on the page, this won't work.  Instead, you could require a user action on the linked page to complete the login process.  Your users would click the link in the e-mail and be taken to a simple page with a login button, and perhaps some text like Log in as <username>?.  Only log them in (and invalidate the login code) when they click the button.  This would require two clicks from your users instead of one, but I don't think that's too inconvenient.

Since the "mail scanner" will only visit the page and not click the button, it won't use up the code.

The more I think about it, the more I like requiring a click.  It doesn't rely on the mail scanner not running scripts so it should be more robust.  You could even combine it with Steffen Ullrich's cookie idea.  If the user clicks the login link in the e-mail and has the cookie, you know they're not the mail scanner so you can log them in right away.  One click and they're logged in.  If the cookie is NOT present, the click might actually be coming from the mail scanner, so you show a page with a login button.  If it's actually just the user on a different browser (or the same browser with cookies disabled), they'll click the button and log in.  In this case it took them two clicks, but that's only a slight inconvenience and it's only necessary if the cookie isn't there.

See this similar question.


Why would I choose SHA-256 over SHA-512 for a SSL/TLS certificate?

From a security perspective, it would be pretty pointless.  In practical terms, SHA-256 is just as secure as SHA-384 or SHA-512.  We can't produce collisions in any of them with current or foreseeable technology, so the security you get is identical.

From a non-security perspective, the reasons to choose SHA-256 over the longer digests are more easily apparent: it's smaller, requiring less bandwidth to store and transmit, less memory and in many cases less processing power to compute. (There are cases where SHA-512 is faster and more efficient.)

Third, there are likely compatibility issues. Since virtually no one uses certs with SHA-384 or SHA-512, you're far more likely to run into systems that don't understand them.  There are probably fewer issues now than in the past, but again, you're buying yourself risk for no gain.

So, at the present time, there are no clear advantages to choosing SHA-384 or SHA-512, but there are obvious disadvantages.  This is why SHA-256 is the universal choice for modern certs for websites.