MD5 has been deprecated due to the ease in which you can find a collision: a few years ago I wrote a paper showing how to generate an MD5 collision in under a minute.  This has since been refined to just a few seconds.

Generating two different postscript documents with the same MD5 sum leverages the fact that postscript is a computer language and postscript viewers evaluate this language.  It's a neat trick.  It works like this: File1 has a binary block Q, then some code, then document A, then document B.   When you display File1, it runs the code which examines Q then displays A.

Now we make a copy of File1 called File2.  We modify only Q to Q' which has the same MD5 sum as Q.  This means that File2 has the same MD5 sum as File1 since nothing else changes.  But now when we display File2 it runs the same code, sees Q' and outputs document B.  Cute!

But here we are using the fact that collisions are easy to find in MD5.  No one (as far as I know) can invert arbitrary MD5 digests, nor can anyone find a 2nd input to match a given file's MD5 sum (this is called "second preimage resistance").

So what you suggest above is still infeasible.  The math you asked for: MD5 outputs 128 bits, so the chance that a random digest will match a given one is $1/2^{128}$ and it will therefore take an expected $2^{128}$ trials to reproduce a desired digest.


Is self signed certificate secure for personal use if verified before access?

Is it secured enough if I manually check my certificate?

What you're describing is essentially Certificate Pinning.  That being the case, the answer is generally "Yes, it is secure, but it's not a recommended or popular method, due to scalability and maintenance issues."

If this is something your setting up for yourself, it's fine; if you're expecting some number of people to use it, you should think about getting a regular cert.  Let's Encrypt is cheap and easy.


How to physically destroy an SSD at home?

The most practical option for physically destroying an SSD is to simply use a hammer. If you can, open the SSD and locate the data-bearings chips and make sure that each chip is sufficiently destroyed. If this is a service you are offering to businesses, however, beware of legal requirements for both data disposal and recycling, and consider investing in something more robust like a drive crusher.

In order to disassemble an SSD, I recommend following this tutorial. When you have removed the drive from its enclosure, I would simply smash anything and everything on this board. It will be significantly easier to destroy the circuit board this way compared to trying to destroy it while it is still inside its enclosure.


DMARC rua indicates mail send from competitorDomain.com for ourDomain.com, is this (potentially) mallicous?

If you're sure that all of your legit mail passes DMARC, including the header FROM domain (example.com) and MAIL FROM (Envelope FROM) domain, something like em.example.com are in alignment, that is, both have example.com as the organizational domain, then you could try a more aggressive DMARC policy to p=quarantine (asks mailbox providers to route non authentic mail to spam) or p=reject (asks mailbox providers to reject any mail that's not authenticated).
Do you know about many emails per week that aren't passing DMARC, say, from this competitor go out? Are any of your email streams, ones that you send failing DMARC? Are any of your own mail streams that are failing DMARC OR SPF?
It's important to be very careful when moving to a more aggressive DMARC policy but if someone seems to be spoofing your domain, then you might consider cutting that off.
Do you feel comfortable calling this competitor or otherwise asking them if there's some misconfiguration on their side whereby they are mistakingly using your domain?


Without exaggeration, what are the practical security implications of the anti-privacy legislation S.J. Res. 34 for the average Internet user?

Congress repealed a rule that had not gone into effect, so 'allows' isn't quite right. The FCC had a rule that would've prevented ISPs from some commercial use of the data they collect.  It was targeted at limiting the violation of ISP subscriber privacy.

ISP vs Destination site (Facebook etc):

Facebook already sells you to advertisers - but the rule would never have applied to Facebook, Google, or any destination site (except when Google fiber is your ISP).

Uniquely identify users:

As long as Facebook uses an encrypted channel (https) the ISP doesn't see your URLs. This leaves the ISP with destination, timing, and message size.  Identifying a unique user based on that data alone would prove impossible*.  Sites without encryption are an open book.

Since you like arstechnica:
"https://arstechnica.com/information-technology/2017/03/how-isps-can-sell-your-web-history-and-how-to-stop-them/"

Information detail:

Technically you're asking a legal question about what data can be shared in absence of an FCC rule.  Given that the laws of particular countries are typically only enforceable on entities within those countries, and given the amount of wrangling that usually accompanies laws, I don't believe anyone knows where the legal lines are drawn.  IANAL

The practical truth is that ISPs want to profile you and sell you to marketers.  This is the primary business model of Google and Facebook.

Arguably, ISPs know more about 'you' (absent a VPN) they can see every domain you visit, and when.
Arguably, Google and Facebook know more about 'you' because you have an individual account with them and they know specific information you access and 'like'.

IMHO Google and Facebook will remain more valuable to advertisers:

Google and Facebook profile individuals instead of locations.
Google and Facebook have a significant first mover advantage.
ISP information will be limited by the increasing prevalence of secure communication, and is nearly eliminated by VPN.
FCC rules aren't the only privacy laws.  ISPs might be vulnerable to defamation suits if they aren't careful.

[*] Theoretically, a determined ISP with a deep understanding of an encrypted site might find ways to fingerprint the various connections required to render a particular URL.  This metadata of the timing and pattern of content/ads served might be user and URL specific, but I doubt it would be economic to analyse as it would require privately held information about the inner workings of a dynamic site.


How concerned should we be about RFID skimming?

The article you point to presents things more from one perspective than the other.

From the same article, I find the statement :"RFID crime isn’t a great payback for the effort and risk." at least arguable.

If you wonder if cards can be read at greater range than stated, the answer is definitely yes. It's all a matter of the quality and power of your hardware. Given the hardware is good enough you can certainly obtain a good read distance.

Considering a few meters is quite accomplishable, this part of the problem is practically solved. High range read is quite possible. It's a matter of basic communications, just like trying to read a radio signal. With a powerful enough receiver you can get signals from hundreds of kilometers away.

Of course the RFID system in the cards is a passive element, but still it can be read from quite a range by normal means, not considering directed energy methods (aka the ray-mode, like a label scanner uses). So yes, I can enjoy my coffee across the street and make everyone on the restaurant on the other side make some 'donations' (and this would only be a beginner method).

The general defense against this is most of the time the limit of the amount transferable. In my country, that amount is the equivalent of roughly 4 Euros or $5. It may not seem much if taken from a person or 2 but if taken from hundreds or thousands it may become profitable very fast.

You will indeed need a relatively complex back-end setup where your reader can actually provide you the transferred amounts, which is actually the risky part the article talks about. This is the reason most current CC-frauds do not rely on such actions - there are other simpler methods to hit high ends of money without resorting to this. Think of it as the equivalent to robbing a very large bank compared to robbing quite a lot of small local ones.

But this does not mean it won't happen.
It is technically very viable and it can be done in such a way to earn extreme amounts of money before anyone ever realizes there's something wrong. It just needs the proper setup (tech setup and key location).

As for the average people, they are not really concerned a lot due to the limitation of the transferable amount. Losing E4/$5 is not much of a damage. But gaining it from a few dozens of thousands of people that can enter daily on a large China-type mall-area can be a big earn. That is why it is increasingly likely that in the future we will see such a large scale skim.

So why not protect if possible ? A foil case for your card is cheaper (you can find them even under $1) than the amount you may lose in only one transactions and you can keep it for years.


HSTS doesn't work on browser when dealing with a self-signed certificate

Actually, this is already answered in stackoverflow :  RFC 6797 Appendix A : HSTS doesn't work for IP address.

You need to setup local DNS server to deal with it.


Self-signed certificates in embedded IoT device

Considering your self-signed certificate is unique per device (which is absolutely should be), then yes there's massive advantage to using these as opposed to plain text or a shared certificate. This raises the effort required to exploit the process which is the purpose of security features. Yes it can be defeated locally, but not in a repeatable way and certainly not against all deployed devices.

You could consider using certificate pinning on your code and validating the server connection in that way. There are issues with this due to firmware images being infrequently updated and servers invariably changing.

The effective solution to this is having factory provisioning of unique signed certificates I'm afraid. You may get away with using a self-signed CA if you also apply certificate pinning.

This is a huge and complex field and I am glad you are thinking of these implications. I work with a couple of absolute experts in the field and we get to see the bad, the ugly and the "don't even want to touch that".

Also plex did amazing things around using signed TLS certs on internal deployments. Yeah it's a tangent but pretty interesting: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/


Getting about 6-7 spam emails every minute

The messages you show mean that somebody is using your email address as a sender. This might mean that your mail account is compromised but it can also be that the attacker got information about your email by compromising users which received mails from you or by simply guessing or generating random email addresses. Email is similar insecure as snail mail, i.e. one can write anything as the claimed sender at the envelope and this means that the claimed sender gets a bounce message if the mail could not be delivered.

Once spammers are using your address as a claimed sender as in this case there is not a lot you can do. If you have no control over the domain you probably can only delete all the bounces from your inbox. If you have control you could configure SPF and DKIM to limit how much your address can be used for spoofing.

For more details see Why is it even possible to forge sender header in e-mail?


Commonly observed attack patterns modelled in Honeypot configurations

While the question is a bit general - the answer is yes. That is the good news, the bad news is that you will have to work.

What do I mean?

There is an excellent threat modeling tool called PTA - Practical threat analysis (you can download it from our web site www.software.co.il).  If you follow the methodology of mapping assets, threats (breaches..), vulnerabilities (people, systems, network, software), and security countermeasures, you will be able to build a fairly good model of your system.  The PTA software will then show you what are the most cost-effective countermeasures based on the asset value, probability of threat occurrence and level of damage/threat.

Regarding metrics - metrics are in a sense the measurement data for a threat model.  Regarding data breaches - not knowing what kind of assets you are trying to protect - it is hard for me to give you a general answer but I would collect metrics from your firewalls/IPS, DLP appliance (if you have one) and Linux auth logs - like the number of failed login attempts, root login attempts etc.

If you are interested in metrics - I would highly recommend reading Jaquith "Security Metrics" - it's available on Amazon.

Hope this gives you some direction


How bad of a practice is it to mount tomcat's manager to Apache2?

I would put this on the same level as installing mysqladmin or phpmyadmin on a public web server. Ideally you would not put applications that can do administrative actions on a publicly accessible location (even when protected with passwords, you are vulnerable to a brute force attack).

Furthermore, Tomcat's manager has been known to have had security flaws, so I would avoid using it from anywhere but localhost.

If I understand you correctly, you are trying to access Tomcat's manager from your office. In that case my recommendation would be set it up behind SSL, and to require an approved client SSL certificate for access - this should make it secure enough, provided that you trust your office workstation.


If I am using a VPN with allowed multiple connections can each user/device be able to view traffic of the other user?

TLDR: No

Long answer:
Although you may be using the same credentials for each device, each device will have to set up and maintain a unique tunnel and will have a different IV for each tunnel.
From server's point of view, you're simply accepting up to 8 different concurrent connections (IP:Port pairs) for the same identifier, be it an username or a certificate.

In case you're behind a NAT device, like your home router, every device will have it's own RFC1918 IP address.
In this case even though the public IP address is the same from the server's point of view, it will distinguish between them by simply looking at their IP:port pair as everyone will be using a different port to communicate to the outside work, courtesy of NAT/PAT translation.

To sum it up: Even if you tried to intercept all traffic, you'll figure out that there's no no way to intercept of infer what's going inside each tunnel. (This is not particular true if the same IV is reused or due to implementation errors or known flaws but that's not the scope of this question.)


SPF and Office 365 email accounts spoofing other Office 365 email accounts

Would it be possible to connect with a random Outlook account (attacker@outlook.com) to smtp-mail.outlook.com or Outlook.office365.com with protocol SMTP, and then craft an email using name@example.com?

Generally not. By default, all SMTP connections to O365 must be authenticated first.

In the case of a domain having a non-authenticated SMTP connector set up, it would typically be restricted to accept mail from specific IP addresses only, i.e. ones that you trust to send email for your domain.

Third party email providers may handle authentication differently, and may in fact be susceptible to this type of spoofing.


BCrypt was well designed, and there was much thought put into its operation. There is a special setting included called Work Factor intended to add work when the attacker tries to crack the password.

These two solutions take the same amount of time to compute.

bcrypt(15, bcrypt(15, bcrypt(15, bcrypt(15, "password"))))

bcrypt(17, "password")

(work factor 16 takes twice as long as 15, and 17 takes four times as long as 15)

There is nothing gain in complicating your code process. Just choose the ideal work factor. I usually suggest adjusting the work factor so that it takes ~100ms to complete (with appropriate brute DoS protection) on your target hardware. (noting that attacker hardware would probably be faster)

If you are looking for ways to improve on this, I would suggest pre-pending Pepper in front of the password. Pepper is simply a random string that is not stored with the hash itself. You can either hard-code the pepper in your application, or save it in a separated text file. (not in the database) I recommend using a pepper with 72-bits of entropy. (12 Base64 characters, or 18 hex characters)

Since BCrypt has a max-length of 55-56 bytes, it may be wise to first run an SHA-256 hash on the Pepper and the Password, to achieve a consistent 32 character hex string, which fits nicely in BCrypt. (otherwise, supposing you used a 12 character pepper, any characters beyond a 43 byte password would be truncated) Thanks @Walfrat.


Email in database security vs performance

Hashing the emails (with or without salt) will make them virtually (without mounting an attack, almost literally impossible with a good, unique salt per hash) unretrievable in your system. I am not certain this is what you want, since you may have use of the email base for contacting users, resetting passwords, and other tasks?

Encrypting the emails on the other hand keeps them usable by your application. If an attacker gains access to the database, they will only see cyphertexts and not the actual emails. Please note the discussion in the various comments about IV: changing the IV is important to keep your cyphertext collection safe from chosen-cyphertext attack. Consider an attacker creating several accounts, and subsequently accessing the database, they would be able to reconnect plaintext emails and cyphertexts.

I accept your application is B2B, so it may not be as exposed as a B2C one, however we read all sorts of hacking stories these days... I don't think it should be discounted.

You are concerned that you would not be able to search by indexed email anymore -- that is true. You are facing a choice between convenience and security.

Either you go with the (IMO wrong and dangerous) advice to keep a constant IV for all encryptions and index the resulting cyphertexts in the DB,
or you find an alternative means of locating a user account, e.g. a username. If your application does not offer it to the users, consider an update.

Do evaluate the benefit/cost of either options...


Identifying a Cheater in Public Voting Campaign

My question is, is there anyway to lookup the owner of an IP address?

Yes, search for Reverse IP Lookup and you will find a couple free services with varying amount of information. It won't be that useful anyway, because unless you can subpoena his ISP, you will not get his name and address. And the ISP will not be willing to cooperate.

  can they mask or give a dummy IP address?

It depends heavily on the platform. Usually the IP returned is the IP used for accessing the form, so you probably can trust the information on your file.

  Any insight would be helpful, if you have any thoughts!

Your priority is to bring fairness to the contest, not bring the cheater to justice. Don't waste any time time to unmask the person behind the cheat, only the cheating votes.

You have a collection of emails, right? Send an email to every address with a confirmation link, linking to a page protected with a good CAPTCHA, and ask again the first and last name for confirmation. This can reduce the amount of duplicate votes you will get, because will increase the work needed to the cheater.

And don't disclose publicly how many votes the contestants have, so you can remove the duplicate votes on the background without the attacker knowing their votes were disqualified. You can then remove all duplicate votes from the same IP address, silently, and have a fairer contest.

But if one of the staffers are involved, it's going to be more difficult to protect the fairness of the contest.


Insecure to require numbers in passwords?

It removes a lot of passwords only if you consider that all combinations of 12 letters were possible passwords. In practice, users don't consider random passwords; they want to use passwords with a meaning and there are not many of those.

In other words, what matters is not the number of passwords which fit into the password entry field, but the number of distinct passwords that the user chooses among (the "generation process"). Requiring an extra digit enlarges that space for most users. Users for which the forced digit reduces the space of possible passwords are users who choose really random passwords, and even at 11 letters and 1 digit, these will be strong.


Virustotal says file is clean but PDFexaminer finds it suspicious

Given that PDFExaminer uses heuristics to examine PDFs, some false positives are likely.  (I'm not sure exactly what it uses to detect the "obfuscation" with eval.)  On the other hand, given that virustotal and malwarebytes predominantly use signature-based engines, some false negatives are likely.  This combination leaves you, as you've noticed, in a middle ground.

If you need to read this PDF and are concerned, I'd consider opening it in a VM.  It's unlikely that they have both an unknown PDF exploit and a VM escape (unless you have reason to believe you're being targeted by a nation state).

If you're interested in learning more about malicious PDFs, I'd manually take a look at the details of the PDFExaminer findings and see what the PDF is doing with eval.  It could be it's some kind of watermarking or copy protection, which (though some people do not like such measures) poses no risk to the integrity of your PC.


PCI-DSS : Sending antivirus logs from private infrastructure to public cloud?

If the logs are originating from machines that contain payment data, then your elk stack would be in scope and have to adhere to all pci requirements, as well as anything that interacts with it.


How to keep track of file authenticity while offline

There is no stricly secure way. If a modification can be applied offline through the official app, then that app needs to have client side everything that is required to build the new version of the file. So a hacker should be able (at least through disassembly tools) to find what the app does and mimic it. But you can make that hard enough to prevent many users to do it. That is essentially called obfuscation. That means an information that is present (the app need it) but hard to find.

If a lot of actual money is involved of if the consequences could be really serious, I would not use obfuscation. If the amount is not mission critical, you will have to balance between the risk of somebody hacking into your app, and the gain of offering many users an interesting feature. I am sorry not to give you a precise answer but it is the best I can do.


Can CVE-2015-7704 - ntpd kiss-of-death affect NTP time servers or just clients?

The vulnerability is about being able to manipulate the polling rate, something that is only relevant to a client. https://bugzilla.redhat.com/show_bug.cgi?id=1271070

CVE-2015-7705 is the CVE for the bug that affects the server (DOS).

The full technical discussion of the bugs is found here: http://bugs.ntp.org/show_bug.cgi?id=2901

In answer to the "stratum" question, you have to look at the definition of the KoD messages:

  According to the NTP specification RFC 1305, if the Stratum field
  in the NTP header is 1, indicating a primary server, the Reference
  Identifier field contains an ASCII string identifying the particular reference clock type.  However, in RFC 1305 nothing is said about the Reference Identifier field if the Stratum field is 0, which is called
  out as "unspecified".  However, if the Stratum field is 0, the
  Reference Identifier field can be used to convey messages useful for
  status reporting and access control.  In NTPv4 and SNTPv4, packets of
  this kind are called Kiss-o'-Death (KoD) packets, and the ASCII
  messages they convey are called kiss codes.  The KoD packets got
  their name because an early use was to tell clients to stop sending
  packets that violate server access controls.

RFC 4330


This looks like a preliminary work for a phishing run.

You may not believe this, but phishing software, lists, networks of bots etc. are actually for sale if you look in the right places.

So we might be looking at a wannabe phisher that has set up his new kewl toyz and attempted to do a phishing run. But something went wrong, some tokens remained untouched (e.g. {{email}} which should clearly have been your email) and the email body is probably still the equivalent of a Lorem Ipsum.

And there's no clickable link.

I saw some specimens with similar flaws, even if not identical to yours, years ago.


Is it better to choose less-vulnerable random password?

In general

This depends on what information you are asuming that the attacker has.

First, let's asume that the attacker is blind, and perhaps trying to crack a large dump of breached accounts, without knowing that you used that specific algorithm. Then you would be better protected if you discarded 123456 if it comes up, or more realistically, passwords that are only lowercase, dictionary words, etc. This is for the simple reason that any attacker is bound to try those first since in general they are more common.

On the other hand, if the attacker knows that your algorithm was used, discarding passwords will only make her job easier. If you dump 10% of the passwords, that is 10% she does not have to try, saving her 10% of the time on average.

So which one of these two scenarios are more likely? I would say the first one in most cases, but only you can determine what your threat model is.

A mathematical example

Let's do some math to see how many passwords you would actually drop. Let's say that characters are picked from three groups (upper case, lower case, numbers + special characters) and let's say that there are an equal number of character in each group. Furthermore, let's say that you require passwords to have at least one character from each group. What fraction of passwords would you drop?

If I get my math right, it is 3*(2/3)^L where L is the length of the password. For L=10 you get 5%. For L=20 you get 0.1%.

Unless you are completely sure that the only threat is an attacker that knows how the password was generated (I find it hard to imagine how you could be that), I would say that reducing the search space by 0.1% is worth it.


Encrypted data transfer with middle node and asymmetric key

This is the model of encrypted emails. So see OpenPGP, in particular its open-source implementation GnuPG. With your notations, node B has a public/private key pair, and node A knows the public key of B. Node A asymmetrically encrypts the message with node B's public key, and only node B can decrypt it, using its private key, which no other node knows. When A sends the message, it actually sends it to some repository server (B's "mailbox"), which B will consult when it goes online again. The repository does not have a copy of B's private key, and therefore cannot decrypt the message.

For the encryption process, node A only needs a copy of B's public key, which is public, and does not change; node A can use B's public to encrypt one billion successive messages without any security problem. B's public key does not "wear off" upon usage. Node B needs not be online at any point for the encryption to work.

There are a lot of tricky details to care of when designing a format for asymmetric encryption, so you are warmly encouraged not to do it, and instead rely on some existing protocol (like OpenPGP) which has been thoroughly reviewed by many cryptographers. Similarly, implementation is also a dangerous part, and you cannot test for involuntary data leaks, so reusing some existing code is also a smart move.

The hard part in asymmetric encryption is how to make sure that what node A considers to be "B's public key" is really the public key of B, not a fake public key whose corresponding private key is known to the attacker. Depending on your context, this "making sure" part can be as simple as a one-time configuration, or as complex as a full-blown PKI.


What to do after falling victim to a remote access technical support scam?

The best way is to reset your whole pc, this is going to wipe all the things in your computer. This is the best way which you can follow even when any malware is present in your system.


The best solution would be to use a local PHP server on a computer without Internet if you want to be safe.

Download PHP, put this text in a .php file, COMMENT OUT ALL THE PARTS YOU DON'T UNDERSTAND YET, and run 'php -S localhost:80' (or even better, take this version I cleaned a little)

Then just add 'echo $variable' to see what's going on, and uncomment lines when you think you understand what it does.

EDIT: This doesn't seem to be heavily obfuscated, the only lines you might be afraid of are the very last ones.

SECOND EDIT: The eval is in the hex string at the end

\x20\57\x2a\40\x67\146\x71\165\x79\157\x70\167\x78\171\x20\52\x2f\40\x65\166\x61\154\x28\163\x74\162\x5f\162\x65\160\x6c\141\x63\145\x28\143\x68\162\x28\50\x31\63\x37\55\x31\60\x30\51\x29\54\x20\143\x68\162\x28\50\x36\60\x31\55\x35\60\x39\51\x29\54\x20\145\x64\161\x68\157\x61\161\x75\161\x70\50\x24\163\x67\152\x6b\160\x62\162\x71\144\x6f\54\x24\143\x72\151\x79\160\x6a\167\x6e\155\x69\51\x29\51\x3b\40\x2f\52\x20\141\x61\155\x72\151\x65\160\x74\167\x75\40\x2a\57\x20

"' /* gfquyopwxy / eval(str_replace(chr((137-100)), chr((601-509)), edqhoaquqp($sgjkpbrqdo, $criypjwnmi))); / aamrieptwu */ '"


If I change any character in a private PEM, should the public PEM be different?

The PEM format is a remnant from an old, forgotten standard called Privacy Enhanced Mail (it was never widely adopted, but served as inspiration for ulterior protocols, in particular S/MIME and PGP). A private RSA key in PEM is really the Base64 encoding of the DER encoding of an ASN.1 structure which looks like this:

RSAPrivateKey ::= SEQUENCE {
    version           Version,
    modulus           INTEGER,  -- n
    publicExponent    INTEGER,  -- e
    privateExponent   INTEGER,  -- d
    prime1            INTEGER,  -- p
    prime2            INTEGER,  -- q
    exponent1         INTEGER,  -- d mod (p-1)
    exponent2         INTEGER,  -- d mod (q-1)
    coefficient       INTEGER,  -- (inverse of q) mod p
    otherPrimeInfos   OtherPrimeInfos OPTIONAL
}

(This is taken straight from PKCS#1, the most used RSA standard.)

What must be noted here is that a private RSA key consists in numerous fields, and among them the modulus and public exponent. This means that the public key can merely be "extracted" from the private key.

With your extra characters, you did two things:

You "damaged" the coefficient value. This is the inverse of q modulo p, where p and q are the prime factors of the modulus. It is used for private key operations, specifically the ones which are implemented with the CRT (a nifty trick which quadruples speed of private key operations).
You added "garbage" after the ASN.1 structure. DER encoding has explicit length headers, so the decoder knows very well where the main structure stops.

In your case, the PEM/DER decoder which you use appears to simply ignore trailing garbage (some other libraries would reject the key with an error; e.g. that's what OpenSSL does). Since public key extraction does not use the coefficient, you get the same public key as with the undamaged private key. However, if you try to use your modified private key, chances are that you won't get proper results (depending on whether your implementation uses the CRT or not).


Do we need VPN to access corporate resources while we have WiFi with EAP TTLS/PAP?

Theoretically the WIFI setup should be secure enough on its own.  However, company wifi is usually provided so that people can hook there personal devices up to the internet ... providing VPN access gives people the availability of internal resources as needed while keeping the rest of riffraff out of the corp network.

This setup is a classic example of compartmentalization ... if your ifruit doesn't need access to anything more than internet for stream music ... why provide access to the internal exchange server.  It significantly reduces the attack surface in the case that your ifruit has some nasty rootkit on it that you didn't know about.

It is generally considered annoying to the people who DO want access to the internal resources, but in most cases these people are the vocal minority.


Is this by default in SQLite or do I need to enable something or check something?

This SQLite cheat sheet

https://github.com/unicornsasfuel/sqlite_sqli_cheat_sheet

says

File writing (php to web folder)    "...requires either direct database access or (non-default) stacked query option enabled..."

Arbitrary Code Execution (load dll)  "...Requires non-default configuration..." and more specifically the link you provided above says "...Unfortunately, this component of SQLite is disabled in the libraries by default ... "

Here is how you enable extension loading

https://www.sqlite.org/c3ref/enable_load_extension.html

sqlite3_enable_load_extension(dB, 1)


Is it possible to put malware in an audio file with steganography?

Transmitting any data inside a playable audio file is already steganography by definition. Humans don't normally inspect the bytes inside an audio file, so any data placed in it that evades detection under normal use is hidden, regardless of whether you classify it as malware.

Other common malware techniques used to evade detection, such as polymorphism and encryption, may contribute to the masking of the hidden data but aren't necessarily steganography.

I don't know if you'd consider it steganography if the data were simply placed in an ID3 tag in an MP3 file, because those tags exist for a human to view and use (with suitable tools, of course.) But if the bulk of the malicious data was encoded in the music itself (like some of the audio watermarking technologies), that would certainly qualify as steganography as I understand it.

For that matter, the data could be hidden steganographically in the embedded JPG image of the album cover, and that would fit pretty much every definition out there.


From the description of your service, your merchants (and I'm assuming they are small merchants, so SAQ eligible) will be required to provide an SAQ A-EP to their acquiring banks. There's lots of confusion in the world about what service providers need to do, so excuse the length of this because there are actually two questions to be addressed.
TL;DR Summary

Your customers need to be PCI DSS compliant, and they will rely on you for some of the evidence to support that. You can have a QSA produce a Report on Compliance (RoC) or self-assess with an Self Assessment Questionnaire (SAQ). You provide the RoC or SAQ to your customer, they use that to complete their SAQ A-EP which they give to their acquirer. Given JavaScript skimming attacks are so prevalent at the moment, having an independent QSA assessment would be good -- especially for a new system -- and if ever anything went wrong, would show you'd not been negligent.

Being a listed service provider by a brand is a completely separate thing and is where the L1 and L2 designation comes from. Each brand has its own rules about who it lists and what evidence (SAQ or RoC) is required. You do not have to do this unless you work with a card brand's customer (i.e. a bank or other financial institution). However, some card brands allow you to choose to do this for marketing purposes.

Providing evidence of PCI DSS compliance to your customers
You are a service provider to those merchants, and you will be responsible for providing evidence to each merchant that you are meeting the requirements in SAQ A-EP on their behalf. So you need to be in a position to provide this evidence.
The best way to do this would be to have a QSA assess your environment and produce a report on compliance (RoC) that you could provide to each of  your customers when they ask about PCI DSS. Although the QSA would use the full RoC template they would only assess you against the requirements in SAQ A-EP, marking the others 'Not Applicable' or 'Not Tested' (that's a long conversation with your QSA). What you're doing is producing the evidence for your merchants to prove their compliance to their acquirer.
Rather than having a QSA do this, you could choose to self-assess, and whether your self assessment is sufficient for your merchants is a question for each merchant - the standard does not make this distinction, it is a question of contract etc. between you and your customers. If you self-assess you should use SAQ D for service providers, but only completing the requirements contained in SAQ A-EP. PCI SSC FAQs 1131 and 1382 are useful.
Providing evidence to the card brands' service provider programs
Now, the question of being a "Service Provider". The L1 and L2 service provider programmes are run by some card brands (Mastercard and Visa). Each has their own separate definition of what an L1 or L2 service provider is (although they are both the same at the moment).
If you want to be 'listed' as a complaint service provider by Visa - given the number of transactions, you would be a L2 service provider and most probably need to provide the SAQ D (with just the SAQ A-EP requirements completed) - I'm no longer an expert on Visa's compliance programs, but this is the page to consult.
Mastercard's listing requires you to be registered by a Mastercard customer. Again here's the relevant page.


Chrome is denying me access to the youtube website and it says incorrect certificate for host

... ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN)

This error is due to a certificate provided by a peer not matching the expected certificate. This is probably due to SSL interception by some middlebox (firewall) or an attacker, which does a man-in-the-middle attack to intercept and decrypt the traffic to the server and re-encrypt it to the client. Since it does not have the private key of the original certificate it needs to use a different certificate for the connection to the client.

Mostly certificates are only checked by building a trusted path to any of the trust anchors (root certificates) built into the browser or OS and by checking that the name of the target matches the names in the certificate. But for important certificates modern browsers have hard coded the expected public key from the certificate. This technique is called Certificate and Public Key Pinning. This way a browser can detect SSL interception, even if a trusted CA certificate is used to re-sign the original certificate.

SSL interception might be used for legal and illegal reasons:

If you are inside a company you work for or in some similar setup, then they might be using SSL interception for security reasons, like scanning encrypted traffic for malware.
If this is the case you should contact your system administrator on how to setup your browser to accept the generated certificates from the interception device.
If you are at home and getting this error somebody might be tampering with the network, maybe by hijacking your router as done in this case. In this case you need to cleanup your network.
If you are at some public hotspot, hotel or similar setup and other requests to web sites work, then somebody might try to attack the network. In this case stay away from further using the network.
Also, there are some countries like Iran which do state-wide traffic control, which sometimes includes SSL interception. This happened in 2011 and was detected by a similar error you got. If you live in such country or travel to it there is not much you can do, except maybe use a VPN which is fully under your own control to route your traffic outside this country. But such VPN might be blocked too.


Is sha1sum still secure for downloadable software packages signature?

I suppose you "use sha1sum" in the following context: you distribute some software packages, and you want users to be able to check that what they downloaded is the correct package, down to the last bit. This assumes that you have a way to convey the hash value (computed with SHA-1) in an "unalterable" way (e.g. as part of a Web page which is served over HTTPS).

I also suppose that we are talking about attacks here, i.e. some malicious individual who can somehow alter the package as it is downloaded, and will want to inject some modification that will go undetected.

The security property that the used hash function should offer here is resistance to second-preimages. Most importantly, this is not the same as resistance to collisions. A collision is when the attacker can craft two distinct messages m and m' that hash to the same value; a second-preimage is when the attacker is given a fixed m and challenged with finding a distinct m' that hashes to the same value.

Second-preimages are a lot harder to obtain than collisions. For a "perfect" hash function with output size n bits, the computational effort for finding a collision is about 2n/2 invocations of the hash function; for a second-preimage, this is 2n. Moreover, structural weaknesses that allow for a faster collision attack do not necessarily apply to a second-preimage attack. This is true, in particular, for the known weaknesses of SHA-1: right now (September 2015), there are some known theoretical weaknesses of SHA-1 that should allow the computation of a collision in less than the ideal 280 effort (this is still a huge effort, about 261, so it has not been actually demonstrated yet); but these weaknesses are differential paths that intrinsically require the attacker to craft both m and m', therefore they do not carry over second-preimages.

For the time being, there is no known second-preimage attack on SHA-1 that would be even theoretically or academically faster than the generic attack, with a 2160 cost that is way beyond technological feasibility, by a long shot.

Bottom-line: within the context of what you are trying to do, SHA-1 is safe, and likely to remain safe for some time (even MD5 would still be appropriate).

Another reason for using sha1sum is the availability of client-side tools: in particular, the command-line hashing tool provided by Microsoft for Windows (called FCIV) knows MD5 and SHA-1, but not SHA-256 (at least so says the documentation)(*).

Windows 7 and later also contain a command-line tool called "certutil" that can compute SHA-256 hashes with the "-hashfile" sub-command. This is not widely known, but it can be convenient at times.

That being said, a powerful reason against using SHA-1 is that of image: it is currently highly trendy to boo and mock any use of SHA-1; the crowds clamour for its removal, anathema, arrest and public execution. By using SHA-1 you are telling the world that you are, definitely, not a hipster. From a business point of view, it rarely makes any good not to yield to the fashion du jour, so you should use one of the SHA-2 functions, e.g. SHA-256 or SHA-512.

There is no strong reason to prefer SHA-256 over SHA-512 or the other way round; some small, 32-bit only architectures are more comfortable with SHA-256, but this rarely matters in practice (even a 32-bit implementation of SHA-512 will still be able to hash several dozens of megabytes of data per second on an anemic laptop, and even in 32-bit mode, a not-too-old x86 CPU has some abilities at 64-bit computations with SSE2, which give a good boost for SHA-512). Any marketing expert would tell you to use SHA-512 on the sole basis that 512 is greater than 256, so "it must be better" in some (magical) way.


How to secure my network, laptop, ipad and email accounts which are possibly hacked?

Is there any way to know how much of my data was exposed? Or stolen? Can I know if they really got my pictures? Or anything else?

  This will depend on your operating system and what behaviour gets
  logged automatically. That you knew that you were hacked indicates the
  hacker wasn't covering their tracks very well.

  Still, most service accounts when someone logs in will provide carte
  blanche access to all assets. So if a specific account was breached -
  assume they took everything. Otherwise it will depend on how much security logging the computer or online web service did and whether
  anyone will want to check these often cryptic audit logs for free.

Is there anyway to secure my network?

  Yes. Many ways to secure a network. Too many list here. But you can start with this guide.

Or do I have to close my email accounts and change my laptop?

  No - you don't need to close your accounts or sell your laptop. But you do need to reconfigure your accounts and laptop.

  For your computer

  Install malware/virus scanner and check that no corrupt apps exist
  on your laptop. You need to do this first to ensure no corrupted
  backup tool re-injects viruses/trojans.
  Restore your computer from a full backup prior to the breach date
  (if known); or if no full backup available: Backup everything
  except applications or anything that executes code; then factory wipe/reinstall your laptop to the original clean operating system
  and then reinstall applications from clean read-only or internet
  sources. Then restore backed up data.
  Install a decent firewall and anti-virus solution.
  (Optional) Request your ISP to provide a different static or
  sticky-dynamic IP for your computer so that the prior attacker can't
  easy find you any more. This can be useful if they were targeting your
  computer specifically

  For online services (email, gaming, forums, digital storage, social
  networking, etc). Assumes that you do this from an uncorrupted computer:

  Get a good strong password manager.
  Log into each breached account (if you can; otherwise contact the
  provider)
  Change the password with one generated by the password manager.
  Longer is better, and never use the same password on two different
  sites.
  Change any secret security questions if you can. Opt for nonsense questions or answer if you can. e.g. Q: What is your mother's maiden
  name? A: E-S-V-F-H-N
  Check that your email address for the account hasn't been changed.
  As many services send password reset links to your account's email
  address.
  Check for any tweaked or altered security settings, such as
  authorised third-party apps, client certificates, public keys, email
  forwarding, account visibility/privacy settings.

This can be tedious, so it is up to you whether you wish to do this yourself or pay an expert to do it. If the time and materials (money) for doing this exceeds the cost of a new laptop and porting content across, then you could resort to truly clean slate of new equipment.


About password_hash() in PHP and storing (part of) its salt outside DB

What is the name of the result format/protocol/convention?

password_hash()  uses the bcrypt algorithm.

  PASSWORD_DEFAULT - Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP. For that reason, the length of the result from using this identifier can change over time. Therefore, it is recommended to store the result in a database column that can expand beyond 60 characters (255 characters would be a good choice).

Source: http://www.php.net/manual/en/function.password-hash.php

  Q2) What i dont get however, is that all of the salt is included in the database. If a badguy® where to obtain these, he has all the puzzle parts. In the past, i learned to put (part of) the salt outside of the database: in source, of even base it on ram/system/hardware values so its not even on disk. Why is this not facilitated, or how should i? Ofcourse i could do a double hash with a different salt, or is there a better way?

The only requirement for a salt is for it to be globally unique. It does not have to be kept secret. password_hash() takes care of it for you. Don't do anything fancy and stupid. See: How to store salt?

  Q3) Also -in the doomsday mindset that security requires- i believe the single-point of failure password_hash() is going to be a high value target, and might facilitate MITM attacks way easier than the more self-contained crypt(). I imagine writing a "bad" algo and setting it as the PASSWORD_DEFAULT algo would be easier than altering crypt(). I have not looked into the PHP backend code/modules however, just speculating.

What? MITM has literally NOTHING to do with this. The hashing should be done on the server. If an attacker can modify files on your server, he can already do whatever he wants.


How does DNSSec work? Are there known limitations or issues?

DNSSec is normal DNS, but with signatures. It absolutely prevents DNS Spoofing; that's what it's for, and that's what it does.
Registrars can still theoretically abuse their position because they're responsible for communicating your intentions to the root servers. This includes information about your DNSSec keys. This relationship will never change; if you can't trust your registrar, then get a new registrar.
DNSSec doesn't prevent MITM attacks. It absolutely prevents DNS spoofing. But there are other ways of inserting yourself into a traffic flow than just DNS spoofing.
How it works
In essence, you tell your registrar your signing key's fingerprint by creating a DS record, and that information will be available from your TLD signed by an upstream key which chains in a like manner all the way to a single globally trusted key.
With this set up, your key is now considered to be the trusted authority for your domain, and is allowed to sign your DNS records. So now for each record in your zone, you create a corresponding RRSIG record which contains the associated digital signature.
Now, when someone looks up a domain in your zone, you can send not only the response, you can also send the corresponding RRSIG record as well which shows that the response was signed by you. To verify the signature, the client fetches your DNSKEY record which contains your full public key, and then just follows normal cryptographic signature verification techniques.
Obviously the DNSKEY record also has its own corresponding RRSIG record so that you can verify that it hasn't been tampered with. But more importantly, there is a DS record available from your parent zone (remember, you gave it to your registrar in the first paragraph) which contains enough information about your public key to verify that your DNSKEY record is actually authorized for your zone.
That DS record is, in turn, singed by your parent's DNSKEY, for which there is a corresponding DS record in the root zone. This way, all key signatures can be traced back to a single trusted source.
Problems
The complication comes when you need to tell someone that a record doesn't exist. Obviously that response needs to be signed, but generally the DNS server itself doesn't have access to your signing key and can't sign the response on-the-fly; the signatures are all created "offline" ahead of time. This keeps your key from being exposed if your DNS server gets compromised.
So instead, you alphabetize your subdomains and say "for every name between mail.example.com and pop.example.com, no other subdomains exist" and sign that assertion. Then when someone asks for nachos.example.com you can just give them that response (which has already been signed) and the client knows that because nachos.example.com falls alphabetically between mail.example.com and pop.example.com, then the "this domain doesn't exist" response is considered to be correctly signed and actually came from you.
The place where this becomes problematic is that by having a set of these negative responses which explicitly state that "no responses exist between X and Y, you can easily map out exactly which domains exist for the entire zone. You know that "X" exists, and you know that "Y" exists, and you know there is nothing else between them. Just do a little more poking at random and you'll quickly be able to compile a list of all the records that do exist.
Controversy
There are two camps in the DNS world with respect to whether or not this is a problem. The first group says:
"So what if people know what zones exist; DNS is public information. It was never meant to be a secret anyway."
To which the second group says:
"This is a security risk. If I have a server named accounting.example.com, then someone who intrudes on my network can quickly tell which machine has the juicy information on it and therefore which one to attack."
To which the first group then replies:
"Then don't call it that! If your entire security model is based on the concept of keeping public information secret, then you, sir, are an idiot."
To which the second group replies:
"It's not about keeping secrets, it's about not revealing more information than you have to."
And so on, ad nauseam.
DNS (and DNSSec) was designed largely by folks in the first camp; DNS is public, therefore being able to map out which subdomains exist in a domain isn't a significant security concern. And anyway, you can't really do signed negative responses any other way.
On the other hand, the servers tend to be run by people in the second camp. They're concerned about the safety of their own network, and they don't want to be giving away any more information than necessary, since they know that all information will eventually be used against them.
So you have a protocol is cryptographically sound and perfectly functional, but which real-world admins tend to be hesitant to implement.
We'll all get there eventually, I imagine. After all, DNS spoofing is more of a real-world concern than any dangers raised by mapping out subdomains. But change takes convincing. So here we are... still.


What's a way to safely test run untrusted JavaScript code?

It depends on what risks are acceptable for you. For some people running browser with a separate profile is sufficient. Some would run it within a separate Docker container. The others would run it within a virtual machine like VMware, Virtual Box or QEMU.


"The Art of Computer Virus Research and Defense" by Peter Szor is interesting, and also references a lot of other materials.


Received 2 "Delivery Status Notification (Failure)" Mails from postmaster@hotmail.com with messages I did not send. Is this an attack?

Its a very common type of phishing.  Most likely they have spoof your address as the sender (From: ) and might intentionally cause a bounce so you would get/open the emails.

You are correct in that it is as bad.  This is specially true if the email is html encoded and it could be executing something malicious and you wouldn't even know it.

Your are always much safer in running outlook in plain text mode only and probably only load html emails from trusted sources.  Your other option is since your using windows (most likely) cause its outlook, you could have your antivirus scan your emails to be safer.

Again though I would opt out to view emails in plain text just to be safe.


How effective is a basic password modification algorithm compared to password reuse

Assuming a foo of reasonable complexity then on the face of it you would get a decent level of password complexity out of it, enough to make it very hard to brute force, whilst still being easy to remember.

As such it is quite suitable for sites that are of medium to low value ie not your bank or email, probably not your social media.

However sooner or later one site you use it for will be compromised and they will have stored it as an unsalted md5 hash and it will be broken.

At that point the complexity of the second part becomes critical. If it is as simple as the first 4 letters of the domain then it may well compromise the entire algorithm and all of your logins.

Literally millions of password cracks from breaches are in the public domain and are analysed by both black and white hats for this type of thing.

Just using a simple algorithm likely puts you in the top few percent of difficulty and a slightly more complex one eg face => gbdf plus a decent value of foo probably puts you even higher.

Even though the lack of reuse does prevent basic credential stuffing, any algorithm easy enough to remember and compute easily by a person is susceptible to automated analysis of existing breach data. Distributed credential stuffing is incredibly hard to detect and whilst your pattern is better than most internet users it would probably be better to use a password manager.

You could also register with https://haveibeenpwned.com

This would notify you if your pattern was exposed in a public breach.


Does outsourcing infrastructure services reduce risk (and improve security)?

Outsourcing, whether it be to managed service providers, developers or other third parties should be structured in such a way as to allow you access to the same reporting and management information as you would have had you kept the service in house. This could include results of security testing, alert and event statistics etc.

As mentioned, these requirements MUST be written into 3rd party contracts otherwise suppliers have very little motivation to include them.

The ISF have been working to develop a standard around 3rd party assurance and the International Standards Organisation have just accepted the draft so once published this will give useful guidance.


All this is just a matter of definition and vocabulary. I have the impression that in your question you are confusing "exploit" and "threat".

A vulnerability is a weakness in a system. This weakness may or may not be addressed by some security measures, may or may not be known.
A threat can be anything endangering the system by exploiting or triggering the vulnerability. A threat can be caused by a voluntary action (someone causes a denial of service by crashing your non redundant server) or involuntary (a fire broke out and caused a denial of service by burning your non redundant server). As you can see, in these examples there is only one vulnerability (the system is non redundant) and two different threats related to this single vulnerability.
An exploit is an implementation of a threat. There can be many different implementations of the same threat.

Take your SQL injection example:

If users' parameter are not properly filtered, a web application is said to be vulnerable to SQL injection.
This vulnerability requires that an attacker has access to the vulnerable page and is able to input malicious content in a way it will be processed by the web app server and trigger the vulnerability. This provides read/write access to the database to the attacker, allowing him to access and modify sensitive information. This is the description of a threat.
A way to exploit this vulnerability would be to put some string A in the field F. This is an exploit. However, using a different string or a different field might also prove to be effective to counter for instance some badly implemented security measures.  Same vulnerability, but multiple exploits could be used.


Are Telegram secret chats secure assuming MTProto isn't?

The objective of Diffie-Helmann (I guess they authenticate DH somehow) is only key distribution.

The objective of MTProto is encryption.

Diffie-Helmann feeds MTProto with keys lets say.  It is in a higher level.  Although MTProto is 'broken', secure key establishment still takes place.  So DH effectively does not fail in its purpose (key distribution).

Having said that, if you are able to break MTProto (say the keylength is small) by bruteforcing the keys in some manner, the issue is still of MTProto and not of DH.

The protocol is as strong as its weakest link.  In this case if we think MTProto is unreliable, then the whole protocol is unreliable.

EDIT
Looking at the specification in MTProto.  I'm not sure to understand the question completely but I believe that you ask if the 'atomic' elements of MTProto can loose effectiveness by poor coupling.
-AES-256 is used for encryption, this is acceptable.
-SHA1 as a hash function is acceptable at the moment.
-Diffie-hellman for key establishment ok (provided there is authentication).  The key established later derives one key for encryption with freshness (time and sequence number) to provide entity authentication.

The only issue I can see for this protocol is if DH is not authenticated.  If this is not the case, anyone would be able to generate the encryption key (both with shared-key obtained in a MITM and the source of freshness transmitted in clear).

For end to end they use AES-256 as well. The fingerprint looks kind of lame though (and re-uses the encryption key).

digest = md5(key + iv)
fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)

In addition it seems they use AES in ECB mode, that kind of sucks as well, but still, overall the protocol seems 'OK' for normal users.  If you are Snowden or Assange perhaps use something else just in case ;)


How to spoof my IP address to JavaScript and other security concerns

So, how can I (the user) feed (spoof) the VPN IP address (which I have in a text file) to any JS that might run so that it all looks the same to the web server?

The detection of local IP addresses you refer to depends on WebRTC. There is no way to spoof the addresses returned during the WebRTC discovery without changing either the browser code or configuration or the script which is used for discovery. You could

switch off WebRTC completely, either by using a browser which does not support it (like Tor browser bundle) or by disabling it using various methods
try to make a script which somehow interferes with the discovery in the Javascript code and report something different. But this script needs to be probably adapted to various sites.

Simply disabling WebRTC is probably much easier than trying to report different values to the server.


How does a dictionary attack use it's "words"?

A classic dictionary attack simply uses each element of the dictionary as a candidate.

Using rules to extend the dictionary is common, and tend to vary from implementation to implementation. A rule set might include adding numbers, concatenating other words from the list, or substituting letters for numbers or symbols. Hashcat has a fairly proficient rule set and the wiki entry for rule based attacks can be somewhat confusing, but the basic idea is that for each word in the dictionary, variants of that word are also tried.

I'm unfamiliar with the program you mentioned, but given the small amount of info available on the web page, I'd hazard a guess that it runs a simple dictionary attack (only the words in the list are checked).


Is it possible for a javascript malware to put keylogger extension in my browser?

As I see the source code looks like obfuscated, when I de obfuscate the source it seems like an phisher ? It is asking for FB credentials also has some FB styling and setting/updating some cookies, the best thing what you can do is clean your cache and try malware scan.


How the NSA can break trillions of encrypted Web and VPN connections

Edit #2 (11/09/15) - I read through a few articles and a paper. See down at bottom for more comments.

I read the article, although I have no direct data on the following, so guess work on my part.

There are a combination of factors going on here.

Nature of DH exchange.
Pre-provisioned Keys.
Unchangeable of Keys.
Known attacks on DH algorithm.

DH Exchange

The exchange requires that the two parties have the Base Prime. It ought to be a Safe Prime (or Sophie-Germain Prime). If the client doesn't have it, the server will send it over. Both parties should use secure random number generators to create their exponents. Computations should be structured such that successes and failures take the same amount of wall clock time.

Pre-Provisioned Keys

Generating large Primes is not hard, but it is for the uninitiated. Having a piece of software that does it for you is best. That software must use a secure random number generator. Most people will just use whatever keys (primes) that have been pre-provisioned out of habit, ignorance or laziness.

Unchangeable Keys (Primes)

It's entirely likely that much of the software in question wasn't engineered to allow a Prime number change. Engineers who author the software are often as ignorant of proper security methodology as the users. I don't mean that pejoratively; ignorant as in "lack knowledge".

Known DH Attacks

Where to start!

A shorter key (768) was well within the ability for a couple of graduate students to compute partial discrete log matrices and attack Sun's network password authentication scheme a couple of decades ago. See reference at end of this Answer. I wouldn't be surprised if the NSA (or anyone) has the ability to compute partials for known 1024 bit keys, today.

The protocol can be attacked by replacing the Prime in transit to the client if the client doesn't have the Prime and requests it from the server.

Even better, DH is subject to man-in-the-middle attacks, especially with a client that requests the Prime from the server, but even if it doesn't. The DH algorithm relies on secure exponents being computed. However, it doesn't rely on any other data - server and client need not prove each other to establish a secure session. If somehow the client's password (or a hash of it) were mixed into the DH key negotiations without any information leakage and retaining perfect forward secrecy, then the client could be assured the server was legitimate. Look up the SPEKE and DHEKE algorithms for a start on this. In any event, NSA as MITM creates two DH sessions, one with the client and the other with the server and records all data while piping between the two. Easy peasy.

The article states that NSA relied on well known Primes to attack the sessions. I refer back to the paper I mentioned about computing discrete log partial matrices. If possible now with h/w advances, 1024 bit keys wouldn't provide secrecy from observer attacks.

Who's to say the machines running the DH algorithms weren't compromised in some other way? Perhaps, they leaked key data or gave it up when queried in the right way? There has been so much information published about how every piece of computational h/w can be compromised by the NSA, perhaps they didn't bother breaking the algorithm unless they needed to, and instead broke into the machines and got the session encryption keys directly?

Edit

Other DH attacks:

Introduce a Prime that is not Safe (doesn't conform to Sophie-Germain Prime criteria of P=2Q+1, where Q & P are Prime). An unsafe Prime P (Q is not Prime) limits the range of the DH function, thereby simplifying observer attacks (discrete log calculations), sometimes trivially. In the context of the algorithm g^(A*B)%P should map 1:1 or 2:1 over the field of P; a bad P can map large swaths of numbers to a computationally feasible small set.
Rely upon poorly coded DH algorithms which allowed (or forced!) small exponents, making attacking the session easier.
Rely upon poorly coded secure random number generators and/or poorly seeded RNGs (ones that used current time or process ID).
Timing attack in which an observer watches how hard (measured in time) a participant works to compute a result and guesses based upon the work properties of the keys (uses that information to break the keys). This is a general attack, not specific to Diffie-Hellman.

Edit #2

I read an article linked through and the twelve author paper posted.

As suspected above, here's the gist of it. At the end I'll add a little bit more on TLS+DH+RSA cipher suite, just to show another vulnerability.

First off, it appears likely that the NSA has broken a number of the commonly used DH Groups (Safe Prime P + Generator g) used for Diffie-Hellman key exchange. As I indicated above, at least a decade or so ago, this attack was completed by a couple of graduate students (still don't have reference) on Sun's 768 DH key used for network password authentication.  The attack is an observer attack, so no man-in-the-middle needed. The work required to break any particular Group is quite large. However, once broken, all exchanges using that can now be compromised.

Theoretically, DH key exchange provides Perfect Forward Secrecy (vs. RSA which does not).  Once the a DH group is broken, any exchange using that group not is compromised going forward, it's also compromised going backward (ie. recorded exchanges can be broken), so no more perfect forward secrecy for that group. It also means that a dedicated attacker could break uncommon DH keys. This is assumed to be possible for 1024 bit keys, so up your key lengths to 2048 for DH. You should already be using larger key lengths for RSA.

Next, the researchers make a number of notable points.  The paper covers Logjam, which I won't explain in detail except to say it's a MITM, cipher suite downgrade attack.  Clever, but not algorithmically complex.

I strongly urge anyone interested to read the paper. It's fantastic. Here's the second paragraph of the Abstract.

  We go on to consider Diffie-Hellman with 768- and 1024-bit groups. We
  estimate that even in the 1024-bit case, the computations are
  plausible given nation-state resources. A small number of fixed or
  standardized groups are used by millions of servers; performing
  precomputation for a single 1024-bit group would allow passive
  eavesdropping on 18% of popular HTTPS sites, and a second group would
  allow decryption of traffic to 66% of IPsec VPNs and 26% of SSH
  servers. A close reading of published NSA leaks shows that the
  agency’s attacks on VPNs are consistent with having achieved such a
  break. We conclude that moving to stronger key exchange methods should
  be a priority for the Internet community.

That pretty much says it all.  Fixed keys, broken by the NSA allows observer (passive) breaking of many of the secure networking protocols. So, don't use pre-provisioned or common keys (if possible) and/or up your key lengths.

As for the TLS+DH+RSA cipher suite, is this safe at higher key lengths?

I would hazard that it is safe from an observer attack, however, it's still subject to man-in-the-middle attacks and here is how.

In this mode, the Server signs its DH ephemeral with its RSA key (Sign((g^B)%P,RSA_Key_Server)). That means, the server's portion of the DH exchange is authenticated. Assuming the signature is valid when it reaches the client and the Server certificate has not been revoked, the client can proceed safely with the DH exchange knowing only the server can complete it.

How, then, is a MITM possible? Two ways, one more likely than the other.  Both rely on the client failing to do a proper signature check.

First, the client has too many root certificate authorities in its key store (many browsers have over 100). Some of these root CAs are not trustworthy. MITM gets a server cert for the remote site in question, sits in the middle and signs with its own cert (Sign((g^B2)%P,RSA_Key_Middle_Server)). The client will validate the signature, assume the server is authentic and complete the DH exchange with the server. Meanwhile, the middle server can run its own client side of the exchange with the real server and watch all data in between.

Second, I think this is less likely. The client fails to check for a revoked certificate and the MITM has the revoked private key, so it can sign as if it were the original, real server. Client won't know because it didn't check revocation. Middle server, again runs another DH exchange with remote, real server and sits in the middle.

Moral of the story is watch your client configurations and up your key lengths.

EDIT #3: Found the reference to the DH attack a couple of decades back:

  B.A. LaMacchia and A.M. Odlyzko. Computation of discrete logarithms in
  prime fields. Designs, Codes, and Cryptography, 1:46-62, 1991.


Firefox security certificate issues: FUD or truth?

You better ignore that commenter entirely. Joey Spinosa is either royally confused or is trolling.

There are many totally inaccurate statements in his comments; mainly from conflating Server Certificate with Certificate Authority Certificate.

Claim 1:

  downloading files ... install these certificates of authority.

Browsers never silently install a Certificate Authority when just browsing or downloading files. If you run an installer or executable you got from a download or somewhere else, it's possible for the installer to insert a Certificate Authority into the certificate store. However, mere browsing and downloading never silently installs a Certificate Authority without additional security prompt.

There are no good reason to use a second browser, as suggested by Joey Spinosa, to avoid installing a new Certificate Authority. If you install/execute untrusted programs, the installer/executable could just as easily install the fraudulent Certificate Authority in all browsers in the system, infecting both your primary and download-only browser. If you run an untrusted installer/executable, you could already be screwed in more ways than just fraudulent Certificate Authority.

The list of trusted Certificate Authority is pre-installed in the browser, and this list cannot be modified by mere browsing or downloading. Advanced users may add or remove their own Certificate Authority into their browser's certificate store from the Certificate UI. Some legitimate anti virus are also known to have installed Certificate Authority so it can intercept and scan inside HTTPS connection.

Claim 2:

  the name of the certificate and it’s origin bear no resemblance to the name of the web-site.

This is only half truth. The domain name of the website is specified in the CN (Common Name) and/or the SAN (Subject Alternative Name) field of the Certificate. In a DV (domain validated) certificate, that is all the information that the certificate asserts. In OV (Organization Validated) and EV (Extended Validated) certificate, the Certificate additionally have O (Organization), L (Locality), and C (Country) field which will also contain the organization's legal name and jurisdiction. This is the name of the organization as registered in the legal jurisdiction. In some countries, Organizations can have different Legal Name than the name that the general public knows them as. In these cases, the organization may put the name they are generally recognized as the DBA (Doing Business As) name, but there is no requirements for them to do this.

However, what's patently false, and indicates that Joey Spinosa really has no clue of what he's talking about, is the examples he gave:

  For example, I like to use Duck-Duck-Go as my preferred search engine. ... The certificate installed in Firefox is titled “DigiCert Global Root CA”. ... ASUS uses a secure site, the title for that certificate is “Baltimore CyberTrust Root”…

DigiCert and CyberTrust are the names of trusted Public Certificate Authorities. Certificate Authorities are like the "notaries" of the internet, they verify the identity of companies that runs a secure website via TLS, and they are obviously not the companies/websites themselves.

Public Certificate Authorities are independent companies that are trusted by browsers to verify the identity of sites and organizations like Duck Duck Go and ASUS. A Certificate Authority performs this by cryptographically signing Duck Duck Go's and ASUS' Certificates after verifying that the owner of the Public Key in the Certificates are the site/company whose detail are listed in the Certificate. Browsers can verify these cryptographic signatures because the browser ships with a pre-installed list of Certificate Authority Certificates. Note that while a Certificate Authority Certificates have very similar file format and structure as Server Certificates, they are used very differently by the browser.

You can check the details of the Certificate, the details of Certificate Authority, and any Intermediate Authorities in the browser security detail screen, by clicking on the lock icon next in the URL bar. This will show you the Chain of Trust, anchored from the Certificate Author, to end at the Server Certificate. Browsers trusts a Server Certificate by the virtue that it trust the Certificate Authority.

Pubic Certificate Authorities obtained this position of trust by convincing browser vendors that they are technically, financially, and legally capable to perform identity verification. The browser vendors requires that Public Certificate Authority publishes their Certificate issuance practice in a document called CPS (Certificate Practice Statement), and the Certificate Authority are regularly audited to ensure that the Certificate Authority conform to their own CPS. Browser vendors also sets up various requirements in the CPS if a Certificate Authority wants to be trusted by default by the browser. Details of this, you should visit the CA/B Forum and the Browser Vendor's CA Inclusion policy.

Claim 3:

  Simply type “startpage.com” or “duckduckgo.com” into your address bar, watch HTTP change to HTTPS and bingo, you just installed a security certificate

This is not quite correct. Server Certificates and sometimes Intermediate Authority Certificates are downloaded by the browser from the Server every time the browser makes a new TLS Session, this is an integral  part of the TLS Handshake. Note that TLS Session isn't necessarily the same as TLS Connection. A browser can speed up TLS Handshakes with servers it had connected to in the past, by performing abbreviated handshake, which does not exchange certificate details. Under no circumstances would a TLS handshake automatically installs a Certificate Authority.


Risk for information not being transmitted when connecting to an evil twin wi-fi spot

Your whole machine is at risk.

The AP can see your network traffic, and also modify it. A typical attack would then modify a page you are accessing to insert malware as an attempt to take over your computer. If you have all updates, AV is enabled, and you click carefully, then the risk is reduced, but advanced malware could still get you.


The string following # is the ‘fragment identifier’ and is normally used to navigate to an anchor element inside an HTML document (but here is used to simulate URL navigation in a single-page-app).

The fragment identifier is used purely by the browser client-side and is not even included in the request to the web server, so you cannot filter it on the server side in IIS or any other server.

(You should not rely on ASP.NET Request Filtering for security. This is only one of the places it fails.)

You could attempt to ‘filter’ it on the client side by including a <script> run before any other script, that sabotages the page and refuses to load any more script if it detects anything it considers ‘bad’ in location.hash, but that's still subject to all the same failure modes of blacklist input sniffing that make Request Validation a waste of everyone's time.


Malware getting root access via "sudo" and "sudo -s"

It depends on where the malware resides. Let's assume you mean : some program running as your user and wanting to get privileges.

Really short X security primer

First, you have to be aware that X does some access control but does not isolate between connected clients. Every client connected to your desktop can query the server to obtain information about any other X client and interact with it.

For example, if you run Skype (or whatever program, open-source or not) on your desktop, it can spy activity : list windows, their titles, take screenshots, log keypresses, even (with some graphical toolkits) figure out the structure of what it's currently displaying. So in theory it can locate if you have a terminal with a root shell opened, send keypresses events to type something there (though not all terminal emulators obey these).

In practice simulating keypresses may be noticed by you (you see that something happened, or maybe the program could just close the window after doing the job to hide it), while plain keylogging is invisible (especially) if the program is authorized to communicate with the outside world through an encrypted connection (instant messaging, audio and video programs for example, that includes Skype, Google Talk, Flash and other plugins).

Reference: The Invisible Things Lab's blog: The Linux Security Circus: On GUI isolation

Answers to your questions.

In situation 1, you basically trust iotop but I guess that's not your point.  Let's imagine a malware connected to your desktop or running as your user. It could try to trick iotop into doing something nasty (by simulating keypresses, etc.) but it would probable be ineffective.

In situation 2, the shell is separated from X, so it's better security-wise.  You have to know that one program running with your user account can write on a Linux virtual console where you're logged in, but it's only inserting characters on the screen, not process activity.  AFAIK you can't trick a program into actually typing something into another Linux virtual console.

Situation 3 is what's explained above.  A program could notice that, type some commands and try to hide the fact.

If you're really concerned, you are probably interested in security by isolation and Qubes.


Using a custom authentication mechanism with SSH

You can write a PAM authentication plugin.


How to redact HTML so it does not end up in PDF

You can use a HTML parser like BeautifulSoup to programmatically remove HTML tags or replace them with tags such as
~~~~~~~~~~
 and add a redacted class to your stylesheet with black text and black background, or just put display:none. Note: replace the redacted information with junk data  - this is key!

Edit: using display:none won't work because a user could just look at the raw HTML. Just replace it with junk characters and stylize them to your needs.


One way this could be accomplished is by spoofing IP and MAC address information for the victim. You would build a website that phishs that information from them (could be a google clone and harvest creds too), and then using tools like macspoof or ipspoof, assume their identity and from Google's eyes, their computer. This would potentially allow you to hijack a Google account without alerting to the compromise of the user.

Edit:

Another potential attack vector is a rogue access point attack which ends up having the same outcome through a different methodology. A rogue access point is configured to decrypt SSL connections and extract plaintext credentials. Systems of this nature are widely available and easy to use. The Wi-Fi pineapple is a prime example of this.


With SSL/TLS, is pre-sharing of a certificate fundamental to avoid an initial active MITM?

For the points 1..3: Yes, that's how it works. There is some initial trust needed, either in the form of a trusted CA which can be used to derive trust into leaf certificates or as directly trusted shared leaf certificates.

As for your implementation problem: I assume that your disc less clients have same sort of read-only medium they boot from because otherwise your trust problem starts earlier, i.e. how they make sure that they boot the correct OS when booting from a network. Thus assuming that the OS they boot is in fact the correct one but that they have no knowledge of who they can trust they have to rely on "TOFU", i.e. Trust On First Use.

Of course one could try to put at least some initial trust information in the systems because even weak trust might be better than no trust. For example each of these system could come with a different certificate installed by the manufacture, all signed by the manufactures CA. This way one could kind of assure on first connect that the peer device is at least from the manufacture and thus make attacks harder. This is not foolproof of course since the attacker might be able extract the device certificate and key from an existing device or modify such device to work as MITM but this way the initial costs of the  attack would be higher.

BTW, this is not a problem restricted to TLS or even to computers but it is a simple question of what information are needed to trust somebody. And if you have no information at all you have no way to decide if communication peer is trusted or not. That's the reason you have various forms of centrally issued identification in real life, i.e. passports, driver license or similar which provide you with a way to derive trust because you somehow trust the issuers of these ID cards.


Best way to secure file removals in Windows remotely

All you need is a file shredder program, there are plenty of freeware ones. Chances are good you have one included with your AV software anyway. These tools over-write the disk sectors multiple times with different data patterns to completely erase their original pattern so that they cannot be recovered even with physical access.


Is it acceptable to group password characters by category?

Interesting concept. For a human and from the perspective of a blind brute force, I don't see a significant issue with doing this.

The transformation you propose does significantly shrink the number of possible passphrase variations, and this is easy to take into account in order to perform a smarter brute force attack. That is provided the attacker is aware of the type of transformation and the spacing between categories. In essence you're relying on the obscurity of your methodology to maximise its effectiveness, and whilst obscurity does have its place, it should not be relied on (it's just a bad principle).

I can venture a guess of how the key space reduces with a very simple example - 5 digits (10) and 5 lower case letters (26) and 5 symbols (considering only 10 possible samples):

No sectioning: 46^15 = 10^26
Strict sectioning: 10^5 * 26^5 * 10^5 = 10^17

This means the total number of combinations without sectioning is 10000000000 times larger than the number of passphrases you can generate with sectioning.


How do I check if a script is safe to run?

In short, no.  Determining if something is "safe" is isomorphic to the halting problem.
The best you can do is to execute the script using an agent you regard as safe.

Keep in mind that one class of exploits involves trusted functions doing things
they're not supposed to do.  Suppose for example that choose your vendor here
installed a back door in the "print" function so that if the printed string was
39549235-052-4-234-2-42-3-29q4er-2348-2398 they would also open a connection to
NSA headquarters and dump the contents of your hard drive.


What's my exposure, and how to close it, from Conexant HD Audio Driver Package, CVE-2017-8360

Risk:
There is no additional "attack surface" created by this issue. In other words, provided an uninfected machine, you are no more vulnerable to attack. The real risk here is that if your machine is/was previously compromised, an attacker could more easily (than having to install their own keylogger) capture your keystrokes and possibly keystroke history (since last logon) via the log file. Many AV products would detect the installation of a keystroke logger, but since the signed driver already includes it, it could be overlooked (although that said I would expect any reputable security software provider to soon be listing affected drivers as dangerous anyway). The only other consideration as pointed out by Modzero, if you happen to be backing up the public user folder anywhere, backups could also include copies of the log file (again IMHO an unlikely real-world scenario).

Mitigation:
We tested it and found that even if MicTray.log is 0 bytes (as is a common occurrence as reported on the internets and my observation), it can only be deleted/renamed if MicTray[64].exe is killed.

As we had about 40 machines affected, we created the following batch file to push out and mitigate the issue. It renames all files to include an underscore and therefore prevent them from being run normally. This allows reversal if required. The only casualty of this workaround is the lack of the relevant system tray and associated functionality (which IMHO is rarely used anyway).

taskkill /IM MicTray.exe
taskkill /IM MicTray64.exe
ren c:\users\public\MicTray.log MicTray.log_
ren c:\windows\system32\MicTray.exe MicTray.exe_
ren c:\windows\system32\MicTray64.exe MicTray64.exe_


What does identical cipher text data mean in cipher block chaining (CBC) mode?

I believe none of the answers is correct. The blocks being the same means the XORs of the previous blocks and the plaintexts are the same. So 60A..388 XOR cleartext-1 is the same as 1F2..CA2 XOR cleartext-2.

So cleartext-1 XOR cleartext-2 = 7f8d68bf68fb3f.

Explanation:

The cleartext data can not both be null because their XOR is not null
The previous chunks (ciphertext) are clearly not identical and even if they were, it would not matter unless the cleartexts were identical as well.
They are not identical (cleartext), but why the offset matter is unclear to me. It does not. Also, I would not necessarily say there is no relation, as I wrote the relation down (what they amount to if they are XOR-ed)
No, they can't be identical. Identical blocks would XOR to all zeros / null.

So the "most correct" is the third one, but IMHO still incorrect.


Blacklisting vs. whitelisting characters to prevent XSS?

It is not just a block of handful characters that you need to blacklist. In security we go by this dogma:

  "There are things we know that we know. There are known unknowns. That
  is to say there are things that we now know we don't know. But there
  are also unknown unknowns. There are things we do not know we don't
  know."

Blacklist might help you prevent the first two cases, a whitelist helps covers all three :)

While it is easy to identify and validate a set of characters that are harmless, its difficult to identify all known bad. Most anti-virus software employ blacklist approach(signatures), however they still fail to catch a 0-day because it was something they didn't know as a known bad and hence didn't have a signature for that.


Authentication, authorization in native mobile clients (Android)

Without understanding more of your app, there are many correct answers to this question.

One common strategy is to use username/password to authenticate to your API. On successful authentication your API will create and return an auth token. Your app will then pass the auth token on each subsequent call.

The typical format of an auth token is

username + other data + HMAC(user + data, secret known only to the server)

When your server receives the auth token on a subsequent call, it parses the username and the other data (whatever you may want to store), performs the HMAC, and then compares it with the HMAC in the token. If it matches then you have a valid login, otherwise you log the attempt and abort.

This strategy allows the server to be stateless as any important information can be stored in the auth token. If you need to maintain a session on the server, you could use an auth token of the format:

session ID + HMAC(session ID, secret known only to the server)

You probably want the session ID to be a secure random number and not a counter or memory pointer as you don't want the client to be able to guess other session IDs even though the client can't forge the token without the secret.


Is storing files under a web server root unsafe if it is handled by PHP and blocked by the web server site configuration file?

You handle the upload with POST requests to a PHP script which checks the file extension and renames the file

You should check the mime type. PHP have mime_content_type function for that. Even if it's possible to fool the mime header and have some code on the metadata of the file, this raises the bar for exploiting your system.

  If I understand correctly, the files cannot be accessed/executed by any means.

Not really. They cannot be executed directly by the shell. Nothing stops any attacker to uploading a script named as script.mp4 and somehow executing bash the-new-name.mp4 later.

Or using a local file include (LFI) vulnerability and use include videos/the-new-name.mp4 and running a code on the ID3 description field. You could remove metadata from the files, so even if an attacker sends a video with a shell embedded in metadata and includes it exploiting a LFI, it cannot execute.

Your Nginx settings are good.


Is there a Plug and Play demonstration kit for various types of attacks?

There are deliberately vulnerable web applications available from several sources, these can be downloaded and run locally and have been created for the type of activity you describe.

The OWASP WebGoat Project is one such example, which has been around a while and can be effectively used on a single machine to demo the principles of web app vulnerabilities.

As a side note, Metasploit is a different beast and is good for demo'ing things like exploiting remote privilege escalation vulnerabilities, and while it can be used on a single machine (with multiple VMs) I find it is more effective with at least two separate machines (one of which will have to have vulnerable software running on it).


how much security does the iPhone factory reset provide

The data on the Iphone is deleted not encrypted as Schroeder mentioned in the comments: support.apple.com/en-gb/HT201252

File shredders write over the occupied space with zeros, though doing this on anything other than a spin drive is not recommended as it diminishes the life of the drive and some drives have smart tech which will just make this method infeasible. (shredders normally go over the space x amount of times)

I will suggest however if you want a way to ensure your data is gone I normally encrypted my device with a crazy long unthinkable password, factory reset and then encrypt again! without saving the keys and/or back up keys and re-encrypting over the deleted encrypted space. This should** keep your data safe.


Exploiting unquoted service path not working

Your service should always return back  to windows service manger(SIM) within a proper amount of time... if your .exe file is a back door obviously it wont return to windows service manager... You can make your donald.exe to start another process and return safely to windows.. the other proc can be your backdoor.Check createprocess example in msn for this.


Why there is no SMS verification on transactions with USA debit/credit bank cards?

A different solution is being deployed in the US for both debit and credit which mirrors to a certain degree a solution that has been in place for much of the EU. Credit and debit cards include a chip that is inserted into a card reader, generating a single-use payment credential that, if intercepted, generally cannot be reused.

Why this system and not another? Historical dynamics and inertia. The US has long had a system where the card, or card + PIN, functioned as a bearer credential. To introduce a new model where the user has to actively verify transactions using a second factor like SMS would require cooperation on the part of retailers, card brands, banks, cell network providers, not to mention users.

Of course there have long been card brands that on exceptional transactions would ask for the customer to call them, or will call themselves, to confirm. But this is the exception, far from the rule. The thing is that as much as it makes the news, fraud is simply not that common in the US, even under the card swipe system. It impacts no more than a single digit fraction of transactions.


Typically, a protected internal network relies on more than just an IP address to determine whether something belongs on the network. This could include, but is not limited to, some sort of software (a la MS NAC/NAP), or physical controls (i.e. are you connected to an approved device). Moreover, typically the edge devices that do routing to your internal network will behave as described by korockinout13, and drop any traffic coming from outside that looks like it is coming from non-routable (i.e. internal) addresses.


Do non-administrator Windows accounts need strong passwords?

Here's the thing: If you're not using full-disk encryption, an attacker can boot from a live OS and plant malware in less than ~2 minutes on any account. Even the administrator account! If encryption is not enabled, a strong admin password does nothing.

So full-disk encryption should always be used.

However, it's good practice in general to always use long and strong passwords. Users should be in the habit of doing this. The layperson doesn't understand much of how computer security works. They don't know or care whether or not a computer is encrypted. But if they're in the habit of using longer passwords, this makes their systems more secure the moment that encryption is enabled.

If full-disk encryption is enabled, the password length/strength will determine how long it takes an attacker to decrypt data.

Also, using a longer or more complicated password makes it harder for someone to stand over your shoulder and just take note of your password as you're typing it in. You'd be surprised at just how many times this simple attack is successful in corporate environments.

Also,

  Nobody is going to try the top 1,000 passwords if they're alone with your computer for a few minutes

Ever heard of ophcrack? If you use one of the top 1000 most used passwords, it can be cracked within seconds. However, this attack can also be mitigated by using full-disk encryption.

If full-disk encryption is not used, using a stronger password prevents only the attacks that require the least amount of skill, such as ophcrack, wherein a script kiddie basically only has to boot from a disk and it'll do the rest by itself. The system still remains vulnerable to many other attacks, such as the one which uses a live OS.

Edit: As OP very correctly points out, having a strong admin password on an unencrypted PC only helps in case an attacker has gained remote access to a non-admin account, which makes privilege escalation attacks harder, and any unauthorized access to data or planted malware remains limited to the single non-admin account that was compromised.


You cannot really test an ASN.1 parser for correction, because it is a complex piece of software and we do not know how to prove that a given piece of software is correct. What you can do is rely on a library with good repute. You might want to have a look at this question. Alternatively, reimplement it yourself; this is not very hard if you stick to a workable subset of ASN.1 (e.g. only DER encoding, only a few string types,...).

.NET necessarily has some built-in code for doing ASN.1 parsing; this does not mean that it necessarily gives you access to that library.

At least, ASN.1 libraries written in Java or a .NET language benefit from the innate resistance of these languages to buffer overflows (if a buffer overflow occurs, an exception is thrown, which is marginally better, from a security point of view, to actually overwriting data in memory).