PCI Compliance Scan Failing for supporting TLS 1.0, but removing support breaks < IE 10

Short version:

TLS 1.0 is on notice as of PCI DSS 3.1
TrustWave is carping, but you may be able to continue using TLS 1.0 if it's not a "new application"

Long version:

PCI DSS 3.1 was released two weeks ago, on 14 April 2015.  It lays out that

  SSL and early TLS are not considered strong cryptography and cannot be
  used as a security control after 30th June, 2016.

In December 2015, the date for migrating existing applications was pushed back two years:

  The Payment Card Industry Security Standards Council (PCI SSC) is
  extending the migration completion date to 30 June 2018 for
  transitioning from SSL and TLS 1.0 to a secure version of TLS
  (currently v1.1 or higher).

  These dates provided by PCI SSC as of December 2015 supersede the
  original dates issued in both PCI Data Security Standard v3.1 (DSS
  3.1) and in the Migrating from SSL and early TLS  Information Supplement in April 2015.

As I understand it, "new applications" must still be implemented in line with the new requirement of 1.1+; the extension only applies to existing applications that used TLS 1.0 prior to April 2015.

The definition of what "early TLS" means is the subject of fascinated debate among QSAs, but it's safe to say 1.0 is part of it (and 1.1?  Could be!  Wait and find out!). (Update - as of December 2015, 1.1 is still "safe")

Here's how TrustWave says they're implementing these guidelines:

  New implementations must use alternatives to SSL and early TLS.
  Organizations with existing implementations of SSL and early TLS must have a risk mitigation and migration plan in place.
  Prior to June 30, 2016, Approved Scanning Vendors (ASVs) may document receipt of an organizations risk mitigation and migration
  plan as an exception in the ASV Scan Report (in accordance with the
  ASV Program Guide).
  Point of Sale (POS) or Point of Interaction (POI) devices that can be verified as not being susceptible to all known exploits of SSL and
  early TLS may continue to use these protocols as a security control
  after June 30, 2016.

So, if it's a new application, you might have to remove TLS 1.0 support.  If it's not, push back on TrustWave and find out what sort of a "risk mitigation and migration plan" they require.

(Pulling the link from @mti2935 up out of the comments, here is Trustwave's Risk Plan Template.  Thanks @mti2935!)


Is it a bad idea to use port forwarding as a long-term access strategy?

Most people consider NAT 'security though obscurity' and is a bad idea. Nat should be used to preserve limited IP address space not as security, a good port scanner will find your servers. Most people use NAT AND a firewall, now they can be in the same box. As was indicated above if you want to talk to a business partner you want to use VPN.


Are Yubi Keys secure "out of the box" when purchased for use with Yubi Cloud?

TL;DR

You may be misunderstanding the security trade-offs that a YubiKey offers. All security controls involve trade-offs; YubiKeys with YubiCloud authentication involves key escrow.

Authentication with YubiKeys

Out of the box, YubiKeys are pre-configured to authenticate against the YubiCloud. The default mechanism appears to involve storing your AES secret key server-side. Yubico claims:

  There is no access to AES secrets even for administrations of the backend KSM servers.

Even if true, I would expect any key-escrow system to be fundamentally vulnerable to physical threats and brute-force attacks. Assuming you trust Yubico to escrow your keys in the first place, anyone with physical control of the Hardware Security Module or its contents could mount an attack.

The bottom line is that if you use the YubiCloud authentication mode, you will be trusting Yubico with your secret key even if you change it. Changing your key only makes sense if you are using an alternative back-end for authentication, or if you believe your currently-stored key has been compromised in some way.

Password Protection in the Personalization Tool

What this feature is doing is providing an administrative password for preventing re-configuration of the key. You may want to look at the source code, but the "Configuration Protection" password is just that: a password to prevent unauthorized changes to the key. Section 3.2 of the API documentation says:

  [T]his approach is targeting destructive attacks as the interface does not provide any means of retrieving secret information. The configuration interface is write only, and the term destructive attack refers to an opponent that wants to erase or modify the settings of a device.

In my opinion, this feature is most useful in preventing end users from misconfiguring or re-purposing an organizationally-owned YubiKey. Your mileage may vary.


Can a document be digitally signed multiple times, successively by different users?

ThoriumBR answer provides a neat solution about how a system with the desired properties could work. However, it is quite crude for the students. You would ideally want an application built upon that that abstracted all the storing prior versions and applying the patches.

Rather than creating a new program for this, I would encourage using a version controol system like Git or Mercurial, that already handle storing files and support attaching digital signatures. This greatly simplifies the task (as there are already tools and documentation) and also provides knowledge on tools they may use later (as opposed to a teacher-specific tool). I would recommend that the teacher provides the server on which they will work, so that he can place the right configuration, such as not allowing history-rewriting, automatically rejecting unsigned commits or even non-fast-forwards.

Actually the usage of digital signatures is not that relevant here, as the teacher will probably trust the server logins, but it's a good exercise anyway.

In any case, the real problem for a teacher would not be that the digital signatures are right, but the social one of each student doing its part and not colluding to give another student some changes they were not supposed to provide or even share passwords and digital certificates with their peers.


Theoretically: yes.

Practically: The use case for this is too small to be worth the effort.

Lets do a very theoretical excursus on how this could be possible:

In theory, every computer communicating with other devices is vulnerable. This is simply due to the fact that interpreting communicated signals always leaves room for error.
If such an error is exploitable a virus could infect a SIM card.

Lets assume the SIM card has been infected; the virus took full control of it. When the SIM card is inserted in another phone the same principle applies: simply because the phone is communicating with the SIM card the phone exposes its vulnerabilities. Thus the SIM card could re-infect other phones.

Back to the real world again:

A virus with the capabilities to infect a wide variety of phones would by far exceed the storage space of any SIM card ever manufactured with good intentions. SIM card manufacturers do (to my best knowledge) not publish documentation on their SIM cards internals. I am very sure that exploitable bugs exist in SIM card software. However, finding those is close to impossible imho (due to the concealment of documentation).


How do I verify a GPG signature attached for a cleartext email using the gpg command line?

Stumbling upon this email made everything clear (as well as glancing at RFC3156).

The email is of type multipart/signed which

  The multipart/signed body MUST consist of exactly two parts.  The
     first part contains the signed data in MIME canonical format,
     including a set of appropriate content headers describing the data.

  The second body MUST contain the OpenPGP digital signature.  It MUST
     be labeled with a content type of "application/pgp-signature".

The signature signs the first part. The first part was actually a multipart of the text and html parts. Every email client I looked at didn't make this heirarchy clear and flattened it into three parts (text, html, signature).

Verifying the signature just using the raw MIME text of the first multipart successfully verified.


Repercussions of disabling sockets in Adobe Flash player?

No issues with disabling sockets. You can always whitelist socket connections

EnableSocketsTo = [ host name, IP address ]

if you have any whitelisted application using socket.connect. nothing breaks that way...


How to minimize security risk when having to work with decrypted (plain text) passwords due to 3rd party API design

I have not used these technologies before but what I can tell you is if you decrypt the password in your SQL query then anyone on your network can sniff and get the passwords as plain text.

If I understand correctly, your C# will get the decrypted passwords?
If so I would recommend you have something such as in your C# application:

C# generate a random key (used for salt in your encryption) and sends salt to stored procedure in SQL.
The stored procedure will encrypt the password based on the salt (from the client)
C# will decrypt it based on salt key you provided

The attacker would be able to decrypt it, if he got the random salt and reverse engineer your C# (which is very easy due to been bytecodes) but least it isn't plain text or static encryption and much better than your plain-text.


TL;DR - Meterpreter will deliver it, but you have to write it first.

You can deliver a payload that includes a .ovpn file and script to run it. However, you will have to write it yourself. Meterpreter has plenty of great payloads that require little or no changes to (like linux_86/generic_reverse_tcp_shell and several variations, where you only change LHOST and LPORT). However, there is not one to deliver an .ovpn. You can create that payload yourself using a combination of a stager and a payload, or multi-step payload.


How does malware such as Stuxnet and Flamer propagate through USB memory sticks?

You are almost correct - .lnk files should be a shortcut to a file, but here the .lnk itself is crafted to effectively autorun an exploit rather than calculate the shortcut to the intended file.

The Microsoft Security Advisory from 2010 gives more information along with the fix in MS10-046 so this is not a zero day.


For sake of simplicity, lets assume you do all of your web browsing using HTTPS.
Now, first consider the case where you aren't using a VPN.  So, your traffic is routed through the ISP, then on to its final destination.  Then, suppose you browse to https://www.somewebsite.com/.  Your ISP can not see the information that you exchange back and forth between https://www.somewebsite.com/, because it's encrypted using HTTPS.  But, your ISP can see that you are visiting https://www.somewebsite.com/, because it can see the packets being sent back and forth over its network between your connection and https://www.somewebsite.com/'s server.
Now consider the case where you are using a VPN.  Because you're using VPN, all of your traffic is routed first through your ISP, then through the VPN, then to the final destination.  If you browse to https://www.somewebsite.com/, your ISP has no way of knowing this, because all they see is packets going back and forth between you and the VPN.  And, neither the ISP nor the VPN can see the information that you exchange back and forth between https://www.somewebsite.com/, because it's encrypted using HTTPS.
With regard to your final question about whether or not the target server can decrypt HTTPS data, the answer is yes.  With HTTPS, the sender encrypts the data, and the receiver decrypts it.  If this weren't the case, then the two sides would not be able to communicate.


Are there any known Python pickle viruses?

If by "virus" you mean "exploit", then you can easily find those even on StackOverflow.

There's probably no widespread malware based on that, partly because there's only little number of applications for popular desktop platforms like Windows that are written in Python, and it's unlikely that any of them indeed uses pickle for the remote data (un-)serialization. However, a Python developer should better avoid a false sense of security here, because it's too simple to write such a malware, as is demonstrated above.


Yes, this is obviously a hack.

Unknown code inserted
obfuscated code
the domain was registered on April 26
chat filters blocking the domain


Is possible to implement a Web Cryptography API custom provider?

See the specification 5.1:

  This specification assumes, but does not require, that conforming user
  agents do not and will not be directly implementing cryptographic
  operations within the user agent itself.

...

  While it is assumed that most user agents will be interacting with a
  cryptographic provider that is implemented purely in software, it is
  not required by this specification. As a result, the capabilities of
  some implementations may be limited by the capabilities of the
  underlying hardware, and, depending on how the user has configured the
  underlying cryptographic library, this may be entirely opaque to the
  User Agent.

Does it answer your question?


When they run the script as a Local Administrator, it fails with access denied.

Then this means that being a "Local Administrator" is not sufficient to run the script. This proves that "Local Administrator" does not cover the full set of rights on the machine. In the context of UAC, a "Local Administrator" does not have the full rights of an "administrator" (as seen by the OS), but, when it asks to do something which requires administrative rights, the UAC intercepts the call and instead of just unceremoniously rejecting the request with an error code, it prompts the user. If the user says "yes, go on", then the process is granted elevated rights. From the point of view of the process, everything works as if it had been a "true administrator" all along.

Services do not run in a session, but "as a service". This means that there is no user to prompt. Therefore, UAC, as configured by default, cannot grant "true administrator" rights on demand.

Apparently, you can configure UAC to never prompt, and instead grant the rights (which basically nullifies the security benefits, if any, of UAC); see for instance this blog post). A better solution would be to run the service as an account which is already a true administrator, not the cheap imitation going under the pompous name of "Local Administrator".


Self sign SSL certificate for my mobile app?

For your particular use case, a self signed cert would be fine.

As you control the app, you do not have to use certificates recognized by browsers, which is the key point of a certificated by a trusted CA.

Functionally, there is no difference in security. See: Does Self-signed certificate differ from CA from a security point of view?


Digital Signatures of XML, PDF and Office Documents on every platform

Disclosure: I work for CoSign.

You're raising the common question of digitally signing data at the network "edge."

Good luck on the idea of signing at the client/edge, for the reasons that you discuss. And forget Javascript, it is completely insecure from the cryptography point of view.

You're right that the signers' private key shouldn't be sent anywhere.

Good news: there is an alternative architecture that will:

Not require that the private keys be sent anywhere
Protect the private keys
Enable signing from clients of all types including mobile, Android, .Net, iOS, etc.
Decrease administrative costs by centralizing the keys and key management

The answer: use a centralized signing appliance. The appliance is hardened at the hardware level: if you try to open the box, the keys are destroyed. Signing appliances are made by my company and some others.

In this system, the document (or better, just its hash) is sent from the edge device to the centralized signing appliance. The user also authenticates with the appliance (using any one of a number of techniques). The appliance holds the private keys. It signs the hash, and returns the digital signature to the edge client.

Depending on the capabilities of the client, it can:

Assemble the signed document itself (combining the digital signature with the source document). Benefit: less data needs to be sent between the edge client and the signing appliance. Issue: requires more sw on the client. Or:

The appliance can return the complete signed document. Benefit simpler implementation on the client but requires that the document be sent to the signing appliance from the edge client.

Note that an entire PDF document doesn't have to be sent back--the PDF digital signature is simply appended to the source document. So the flow can be:

Send the entire PDF for signing. (Or just send the hash if the client can calculate it.)
Receive back either the entire PDF (signed), or just a "tail" that, when appended to the source PDF creates the signed document.

Multiple data types
My company supports signing of PDF, Word, Excel, XML and other document types out of the box. Eg Word documents are signed using the Word "standard" -- a digitally signed Word document can be verified by a recipient (relying party) without installing anything beyond Word. No plugins, etc.

Signer Authentication
Signers need to authenticate themselves with the centralized appliance. My company supports multiple types of authentication including OTP and 2FA.


Should user input be validated for its length in PHP (server side) as a security measure?

As a general rule, you should restrict user input as much as possible, but not more. A field designed to hold the name of towns don't need unrestricted length. But if you cap the length at 25 thinking no names can be longer, you will upset the Welsh.

Shorter input lengths means less space for payloads if you are worried about e.g. SQLi or XSS. It could therefore be seen as defence in depth against these attacks. But if it is your first line of defence, you are in deep trouble... Focus on getting the fundamentals, like prepared statements, right.

Finally, you are right that any restrictions you decide to use must be enforced server side, and not on the client only.


How to prevent a virus from stealing data when I transfer files between offline and online computers?

There is no simple way to move files between computers and preventing other files from being moved. Yes, what you described is not only possible for malware, but was famously pulled of to destroy Iranian centrifuges by the Stuxnet virus.

As for some of your ideas. Most of them won't work. The virus can just write into unused space on the storage device and there is not a simple way to detect or prevent that. You could try to chceck all used space and overwrite unused space, but how would you prevent the device performing the overwrite from getting infected as well?

Using bluetooth is potentialy even more dangerous, as it is similar to just connecting it to the internet.

Transcribing data manually is about the only foolproof way of doing this, though a more reasonable level of security can be achieved using flash drives.


Is possible to track people using Whonix?

From the tor homepage:

"Tor does not provide protection against end-to-end timing attacks: If your attacker can watch the traffic coming out of your computer, and also the traffic arriving at your chosen destination, he can use statistical analysis to discover that they are part of the same circuit."
https://www.torproject.org/about/overview

Also, tor & other tools, such as a browser used while on the tor network, can have vulnerabilities which can de-anonymize you. These have been actively exploited by government agencies.
Recent example:
http://arstechnica.co.uk/security/2016/12/tor-releases-urgent-update-for-firefox-0day-thats-under-active-attack/

Older, similar example:
http://arstechnica.com/security/2013/08/attackers-wield-firefox-exploit-to-uncloak-anonymous-tor-users/


How to test image upload vulnerability in a mobile application?

One of the most important laws of security: Never ever think about trusting the client. No exceptions.

If your client can send any file for you and have direct access to it later, you are asking for trouble.

If your files are pictures, make sure they are really pictures. Searching for .png on the extension or Content-type: image/png is not enough. You must use functions to really detect a picture.

And you must not let users direct access the files. Get the file, put on a folder inaccessible to the webserver using a generated name, and use a file to send the image to the client, using fpasstrhu() or something like it. If possible, apply some transformation to the image.

Does not matter if it's a mobile application, a desktop application, an API or anything: the server is the same.


It can be either, depending on the purpose of the monitoring.
InfoSec needs to monitor in order to respond to issues quickly and efficiently so that risks are limited right now.
Governance, Compliance, and Audit will want to monitor in order to ensure that the controls, processes, and policies are working as intended and having the intended effect over time.
However, every organisation can have different resources and needs, and Infosec might also gather and review data for compliance and audit purposes. This is most common in small orgs with small teams where only the infosec people really understand the compliance issues and what the data means.


Does a SIM card still require a PIN even after being deactivated by the SIM-providing company?

Yes.

Provider companies does not cancel the SIM by sending some kind of data to it, instead they blacklist the identifier of it so celular instruments does not accept requests from that specific chip. Since unlocking the SIM card has nothing to do with carrier services and it occurs internally between the phone and the SIM, you can still access to data inside and even use it as a data storage.

However, it wouldn't be possible to access celular services.


Do I have to hash users' IP addresses when I log them?

So IPs can in fact be considered to be PII (or personally identifiable information) in some cases, so you're right to want to consider whether you need to protect them. Generally this doesn't mean, however, going to any additional lengths beyond how you would protect other PII, say, email addresses for example.

In any case, traditional hashing is likely going to be an ineffective mechanism.  There are only 4 billion IP v4 addresses potentially in existence, and the reality is that you're probably dealing with a far smaller address space that that.  This means that it's relatively easy for an attacker with the hashes to compute the IP addresses that result in those hashes.  Salting is generally not useful in this case, because you presumably want to know when two requests are associated with the same IP address, and you will not be able to easily compare an existing hashes to the hash of the IP address associated with a new request if all of the hashes are uniquely salted.

You could, potentially use a keyed hash without a salt, using a function like HMAC.   This, presuming you can keep the key secure will lead to hashes that can be compared to each other, but also cannot be associated to the IP addresses that were used to create them by an attacker who has the hashes, but not the key.  If the key is obtained by the attacker however, this is no more secure than traditional hashing.

Generally speaking, I'd suggest that the risk here doesn't demand the complexity of a mitigation of this level.   I think the complexity you're adding (and need to maintain) probably outweighs the additional security you'd get.   However, if for your application does in fact require you to consider IP addresses to be sensitive enough to warrant extraordinary protection, consider using a keyed hash function.


Why are USPS, the Washington Post, Oracle, and MailChimp blocking our home network from accessing their sites?

All of these sites are behind the Akamai CDN. The message and code indicates that your cite was blocked by Akamai. As for why Akamai might have done this see Why is Akamai blocking me?. Notably it might block an IP address if this IP was the source of potential malicious activity, like attempts to attack sites protected by Akamai (SQL injection, ...), web scraping, vulnerability scanning etc.

I recommend to check if any of such activity might have been purposefully originated from your network or if there is some infected system which (for example as part of a botnet) was misused by an outside attacker for such activity.

Akamai also provides a tool to check your IP address: Client Reputation Overview. Maybe you can get more information about the cause of blocking there.

  When I apply this change to the router, everything opens back up for about a day, and then by the next day the blockage has returned. When I revert back to the router's default MAC address, the issue remains.

Given that the MAC address of your router visible to your ISP my only explanation for this behavior is that you automatically get assigned a new external IP address when the MAC changes. Given that this only works for a limited time it is likely that the issue causing the blocking is an ongoing problem in your network.


Is it possible to add an x509 extension to a certificate after creation?

You are correct that you cannot add an extension to an existing certificate.

Adding an extension would change the contents of the tbsCertificate portion of the certificate, and that would invalidate the signature on the cert.

Producing another certificate which is in all other respects the same (but has this extension) is theoretically possible if you own the CA.  If not, you'd just be submitting a new request, and that would mean you get a new serial number.  (Either way you'd get a new Thumbprint/Fingerprint, since that's a hash of the certificate, and not an intrinsic value).


Does eliminating the possibility of repeat words make Diceware passwords significantly less secure?

This might get better responses in crypto.stackexchange.com or math.stackexchange.com, but I think I can give you the gist of it.
If we step away from words and take a look at some numbers it might help to illustrate.
Take for example a four-digit code for a lock.
There are 10 possible digits (0-9) and four spaces where they can be entered, so there are 10 * 10 * 10 * 10 = 10^4 = 10,000 possible combinations.
If you say there can be no repeating digits, then on the first space you would have 10 possible digits, on the second 9, on the third 8, and finally 7 possible digits on the last space. This leaves 10 * 9 * 8 * 7 = 5,040 possible combinations, or, about half.
If we apply this to your password maker, we would take the total number of words you are using as possibilities (most Unix systems come with an English dictionary with around 200,000, so we can use this number for now), and the total number of words in your password (using 6 as the minimum Diceware recommends).
This means that without any restrictions on repetition, there are exactly 200,000^6 = 64 nonillion possible password combinations.
If you were to disallow any repeating words, there would be 200,000 * 199,999 * 199,998 * 199,997 * 199,996 * 199,995 ≈ 63.995 nonillion possible password combinations.
That is a difference of approximately .00008%.
As you can see, with a dictionary of at least 200,000 unique words and a keyspace of six words, the difference between no password restrictions and and limiting repeating words is negligible.
This difference would then have an equally negligible effect on the password's resistance to cracking.
EDIT
LieRyan has pointed out Diceware uses a wordlist of 7776 common, easy to type words. If we wanted to see the difference with a list of that size, it would look something like:
No Restrictions: 7776^6 ≈ 2.21 sextillion possible combinations.
No Repeats: 7776 * 7775 * 7774 * 7773 * 7772 * 7771 ≈ 2.2064 sextillion possible combinations.
Difference: ~0.19%
Let's take a look at what that means to someone trying to crack your password.

Assume your adversary is capable of one trillion guesses per second.
-Edward Snowden, 2014

If we take this estimate (emphasis), we would divide the total number of possible combinations by the number of guesses/second to get the total seconds taken to bruteforce every combination of the wordlist.
That is, 2.2 sextillion combinations / 1 trillion guesses/sec = 2.2 billion seconds = 69.72 years (compared to 70.03 years without password restrictions)
This is the average time it would take a well-funded and equipped password cracker (with access to a copy of your wordlist) to bruteforce a password made with this method.


Is SSH public key authentication sufficient for protecting a server if IP Whitelisting is disabled?

How much of a security risk is it in the short term to drop the white list while we work with this developer?

Quite much none, if you and the other developers protect their keys (store encrypted files, have encrypted hard drives) and password authentication is disabled in the SSH server.

If you disable password authentication, the targeted attack using guessing public key (and private key) does not make sense, unless somebody leaks the private key (somebody computer is infected by some virus/malware or stolen with unencrypted key/hard drive).

Note, that you can set at least others developers keys to be accessible only from specific IP, by prepending from="pattern-list" in front of the public key in authorized_keys file. Since it can contain also patters, you can create a mask for your "dynamic" developer too.


Yes - Security certificates are tied to a domain (even example.com and www.example.com would technically need two certificates or a multiple domain certificate). You can get a wildcard certificate, but I think they are still very expensive and work for one second-level domain.

Yes - I think you should be OK submitting across domains since you (presumably) own both sites. You'll probably want to check the referrer in server-side code to ensure it is coming from a site you intend it do (spam control and security), and it'll give you a place to return the user.

You may run into cross-domain issues, but I think you'll be OK. You should be able to have the form hosted on one site, but it will post data to the secure site.

Credit for this to the answer below from @AJHenderson - Use StartSSL. I had no idea. I upvoted his answer for that reason. I'm now using individual StartSSL certs for SPDY on Nginx on several domains, on one IP. It works on newer browsers, however I don't care much about browsers/OSes that can't handle it due to the content of my sites.


Having sudo mode in a web application, why use a password instead of one time passwords?

A second factor is not inherently more secure than a password. In many cases (like an RSA SecurID Token) the second factor is vulnerable to physical theft - whereas a memorized password isn't.

It would be more secure to ask for both authentication factors. I imagine github have chosen not to do this for convenience - after-all this is re-authenticating a user who has already successfully authenticated with both factors. You could argue the active session is already a secondary form of authentication.


Why are there few (none?) easy to use encryption libraries?

Because encryption is complex. There are many pitfalls to avoid and dire consequences that can happen if you get it wrong. The answers to one of my question explores some of the reasons pretty well. At what level of abstraction should a developer work with with regards to cryptography?

That said, there are some nicely abstracted crypto libraries out there. The Fernet library provides a easy to use interface for symmetric encryption in both Ruby and Go. The Keyczar library has implementations in several languages as well. Lastly, a personal plug for a project I am involved with, the cryptography library for python aims to provide both high level crypto recipes and low level primitives with ample documentation on best practices.


Intercepting Android app traffic with Burp

First thing to remember is that Burp is a HTTP(S) proxy. It doesn't do anything about any data which isn't HTTP(S) (OK, except websockets). Android apps, on the other hand, can use any protocol they want. Lots do use HTTP(S), just because it suits the type of data they're sending, but it's not actually required.

Where an app isn't using HTTP(S), that traffic won't appear in Burp. The most obvious example of this is DNS traffic - you won't see any DNS lookup requests showing up even if you're using a browser via Burp.

So:

Apps which completely refuse to work. They could be using certificate pinning - two options here, though. First type, they're looking for a valid certificate for the target site to be installed on the device. In this case, installing the Burp CA cert would make them work again. Second type, they're using some custom pinning, which requires either a specific certificate to be provided by the server, or a certificate signed by a specific entry in the trust chain. These ones won't be fooled by the Burp CA cert.
Apps which work without any packets being captured. They're probably not using HTTP(S). This could be things like SSH clients, messaging services like Whatsapp, or games, where the loss of a packet is less important than most packets arriving fast, which would better suit a UDP based network connection than a TCP based one like HTTP. They might also be ignoring any proxy settings which are in place, especially if you're just intercepting using a HTTP proxy app. To view this data, you'll need a tool like Wireshark, which can handle other types of data, and a wifi card which supports monitor mode.
Apps which only show some traffic. If the traffic you're seeing is stats packages or adverts, they probably fall into class 2 above - most stats systems appear to use HTTP(S) because it's relatively easy to implement in anything, and you generally have to have some kind of HTTP connection open to download adverts anyway.
Apps which don't actually connect out. There are some applications which look like they should be connecting to the internet, but actually don't, or only do so on an irregular basis. These can include timetable apps, some games (where the high scores are updated daily, for example) or anything where it's possible to store data locally for the most part (mapping apps may store the "usual" area locally, and make calls out for reviews of attractions or more distant places). In this case, you might not have seen them try to connect whilst you were watching.

I'd suggest looking at the traffic with Wireshark, if you can, and see what protocols are being used, then dig into interesting ones using appropriate software, bearing in mind that some are intentionally difficult to inspect - encrypted packets from Whatsapp should be unreadable, else they've got something badly wrong!


Checking Browser Agent String for application security

Don't use the user agent for security purposes.

It's not reliable and easy to change. As others noted, every browser can set the user agent to an arbitrary value. It's just an information header that you may decide to send.
It's not private and easily predictable. There are lists of the most common user agents. So an attacker can either make educated guesses or lure the victim on an own site to log the user agent string and use the obtained value.

The problem you describe is also not a session fixation vulnerability. It's acceptable behavior that the same authenticated request works from different locations. For example, when logged in on Github you could extract the user_session cookie from one browser and simply use it on another machine. Since an attacker doesn't easily get access to your browser's cookie jar, this is not a general security problem.


Is there greater risk to browsing websites with invalid certificates than websites with no certificate at all?

Yes, sites with invalid certificates do expose you to more risk than regular HTTP sites with no certificate, though only slightly more.

In terms of the security of the connection itself your intuition is correct; a site with an invalid certificate is no worse than a plain HTTP site. In fact, in the (rather uncommon) case where an attacker is capable of passively observing your connection but not of modifying it, an HTTPS site with an invalid certificate is actually just as good as one with a valid certificate. Against active man-in-the-middle attackers however, HTTPS connections using an invalid certificate aren't much better than plain HTTP.

The security of the connection itself isn't the only consideration here though. There are other important differences between visiting a plaintext HTTP site and an HTTPS site with an invalid certificate which may make the latter scenario somewhat more risky.

For one, sites which use HTTPS connections may be more likely to transfer sensitive information over that connection. Cookies marked with the "Secure" flag, for example, will not be transmitted over unencrypted HTTP connections, but will be transmitted over HTTPS connections with an invalid certificate if you bypass the security warning. This means that if you logged into a site previously when it was using a valid certificate, then came back to it later and it's using an invalid certificate, bypassing the security warning could instantly give an attacker access to your account.

Additionally, some of the more powerful features of the web are, for security reasons, only available on sites which use HTTPS. If you bypass the security warning for an HTTPS site with an invalid certificate, you could be giving an attacker access to these features.

For example an attacker might install a Service Worker for the site you're accessing, allowing them to control your future communications with that site even if you later go back to accessing the site over a secure connection with a valid certificate. Or if you previously granted that site access to the Geolocation API, an attacker would be able to use that access to monitor your GPS location. For a full list of APIs that are only accessible on HTTPS pages, see the Features restricted to secure contexts page on MDN.

Overall though, these additional risks are relatively minor compared to the risks that using an insecure connection in the first place already exposes you to. You should exercise caution when browsing plain HTTP sites, just as you would when accessing a site after bypassing a security warning, as both of those scenarios are quite risky.


Is there a loss of entropy by hashing an N-bit random key to produce an N-bit hash?

Hashing is a deterministic process which means that it can never increase the randomness. But of course it can decrease the randomness: if you hash a 200 bit random value with some hash algorithms which only outputs 160 bits (like SHA-1) then of course the resulting value can never have 200 bits randomness.

But as long as the number of input bits is significantly lower than the output size of the hash it will not reduce the randomness, providing a cryptographic hash is used. If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash. And you are right that collision resistance does not matter for this.


Why protect files with sensative information with .htacces?

So you're storing database passwords and cryptographic secrets in a file within the web root, possibly because low-end web hosting has no other storage for these secrets. Entering this file's name as the path in an HTTP GET request will retrieve its contents. Even if you provide "no web based file explorer", a malicious user may still end up correctly guessing the name of this secret key file unless its name is cryptographically random. Or someone who knows the file's name may leak the name to a malicious party.

The .htaccess file in Apache HTTP Server, or analogous files in other web servers, is designed to prevent direct access to a file through the web even if a client knows its name. This is helpful in two situations:

Say you store secrets in a JSON file that your PHP script loads with file_get_contents() when it starts. The .htaccess would block a user who keys in the URL of this JSON file.
Say you store secrets in a PHP script containing assignments to global variables, which your PHP script includes with require_once when it starts. For example, MediaWiki's LocalSettings.php uses this approach. Normally, a variable-setting script would fail to produce any output. But I've seen occasional situations where mod_php or the CGI handler accidentally fails to load, which causes Apache to instead serve PHP files as plain text, including your secrets. The .htaccess would block a user who keys in the URL of this PHP file.

But be careful: .htaccess does not prevent access through a script, such as if a script takes a filename as an argument and returns the contents of that file. So make sure all scripts that read files with variable names, such as image-serving scripts, sanitize their paths by canonicalizing them (realpath() and friends) and then limiting them to a specific directory.


I'd like to start with a quote of the FAQ of the MIT pgp server:

  Yes, there have been reports of spammers harvesting addresses from PGP keyservers. Unfortunately, there is not much that either we or you can do about this. Our best suggestion is you take advantage of any spam filtering technology offered by your ISP.

Other than that:

If you rather keep an email address as private as possible, you are free to exchange your PGP key for that address using the same safe channel that you transmit the address itself.

So, if you do not upload the key, you can still distribute it privately and use it, without running into spam problems from that harvesting vector at least.

And to follow up with the comments on the question:

In order to be able to programmatically process the data (e.g. search for the email, the name, make sure it gets sent right) there has to be specified how to access the data. This specification can then be followed by the spammers too.

You could use obfuscation that cannot be computationally easy deobfuscated. But then, your email program would no longer be able to match keys with email addresses when sending messages - or require much more user effort on the key management - which really seems to much effort for most users like it is now.


Is this method of 32 char hash generation secure enough for online-based attacks?

Microtime() is an incremental value, not a source of random values (quite the opposite). Using this as a source of randomness causes the output to be... More predictable. It drastically reduces the key space of your hash method to a range that can be guessed reasonably well.
Your colleague generates their hash using md5(random()), you md5(microtime()). To predict one of your valid tokens the attacker needs to work out an approximate time and generate hashes using microtime() of around that time frame, more or less seconds or minutes. To attack your colleague's hash you need to test the entire key space of random(), that is significantly more expensive computationally.
Argument: "the attacker does not know how the hash is generated". Maybe, but now you are relying on obscurity to keep your method secure.
Argument: "nobody would ever bother to do this". Well, given enough intention they would.
Argument: "did you spot the str_shuffle()?". Now I have. It does somewhat increase complexity and thus effort to break, but the first thing that's written on the function page is 'this function is not cryptographically secure'.
Argument: "I have other controls around how the token is used". That is a good one, you could have relatively simple hashes for this and a short expiry time for the token as well as ensuring it is used only once.
My own argument: "Wy bother reinventing the wheel and not just use a decent randomness generator to produce good random strings for hashing?"


It's not matter of firmware vs. software it is a matter of execution of authorized code. How does it happen? Read about Trustable Execution Environment (TEE). There can be different implementations with using same CPU or not. If you'll read about ARM Trust Zone it will give you top level explanation how CPU supports this mode. Basically security is started from signed boot loader, loading Secure OS, setting memory protection zones. Later under supervision of Secure OS only authorized Trusted Applications will be loaded by Secure OS, and executed in protected zone where Host OS has no access, except communication channels using a shared memory.

Those who want to know more about Trusted Executable Environment, at first I would recommend you read here.

https://www.op-tee.org/category/blog/
start with
https://www.op-tee.org/blog/hkg15-311-op-tee-beginners-porting-review/
another source to read
https://www.arm.com/products/security-on-arm/trustzone

May be I'll add more links later.


Proxy Server options for school administrators

It may be easier for you all to use a DNS service such as OpenDNS where you can block based on hostnames and/or web categories. This will be a lot easier to setup and maintain if you are not very familiar with IT. Here is the direct link to their web content filtering - https://www.opendns.com/web-filtering


Yahoo account "secure" but spam sent from my address

As mentioned by @schroeder, it is easy to fake the sender address when sending an email. Because of this, the value of a stolen account is not the address itself but its contacts.

The value in sending spam with a faked origin is to make mail seem to come from a trusted origin. By stealing your contact list and/or the list of people you have emailed, spammers are able to send everyone you know messages with your name on it. You might not trust an email from money@freemoney.biz but would you trust a hair product recommendation from your wife (or more precisely her email)? Often, the answer is yes.

If you are wondering if your account was compromised, ask your friends. If your account was hacked, they'd probably notice the recent increase of spammy emails with your name on it.

In addition, you can return the favor by telling your friends if you suspect that they've been hacked. While I don't suggest doing this by emailing them back (since that might alert a spammer that you are receptive), you could casually bring it up in a conversation (your mileage may vary ;)


Bitlocker lock removable drives at logoff

BitLocker is a system-level feature, not a user-level feature, and this apparently also applies to removable drives. @Joe's answer is accurate but not complete, as you would still need to manually run that command each time.

If you want the drives to be locked automatically when you log off, you should

Create a script (such as batch file) that executes the manage-bde.exe -lock <x>: -fd command for each drive letter <x> that you want to lock.
Use gpedit.msc (the Group Policy Editor) and go down the path User Configuration → Windows Settings → Scripts and assign that script as a Logoff script.

More info on setting a logoff script, with screenshots, is available here.


Personally I always run Suhosin on all my servers.

My main reasons are

Adds sha256() functionality to PHP.
Does some really good stuff in regards to filtering uploads done via PHP.
Disables some of the nasty PHP functions like eval(). Which is good as although you may very well not use it you can never tell what developers will get up to.
Also every other reason listed here is a good enough reason to run it.

Looking at the benchmark results for Suhosin the performance loss is insignificant at least to me.


How to secure (encrypt, password protect) external hard drive used with Windows 7 and 10?

Your best option with windows is BitLocker and it should be working already with windows 7 but in case you do not have it you can easily download it for free from:

https://www.microsoft.com/en-us/download/details.aspx?id=4794

You only need to enable it once and it will work.

From windows 10:

Sign in to Windows with an administrator account.
Go to Start, enter encryption, and select Change device encryption
settings from the list of results.
Select Manage BitLocker, select Turn on BitLocker, and then follow the instructions.

There is also available option when you right click the drive click "Turn On BitLocker"

More details form technet:
https://technet.microsoft.com/en-us/library/ee424323%28v=ws.10%29.aspx

Edit:
Your windows will detect if the hard drive is encrypted with BitLocker and will inform to provide a key. SyncToy will work normally after unlocking the drive.

Edit: based on @WhiteWinterWolf comment
Windows 7 - depend on the edition - may not have BitLocker available already or for install. When the external hard drive used with this kind of windows it will install BitLocker to go reader which all the read of data but no adding or editing. In this case the best option if you choose bitlocker is to you windows upgrade anytime feature of windows 7 to get the version that support (paid option).


Is "the oft-cited XKCD scheme [...] no longer good advice"?

The Holy War
I think you will find that the correct way to generate passwords could start a holy war where each group thinks the other is making a very simple mathematical mistakes or missing the point. If you get 10 computer security professionals in a room and ask them how to come up with good passwords you will get 11 different answers.
The Misunderstanding
One of the many reasons there is no consistent advice about passwords is it all comes down to an issue of threat modeling. What exactly are you trying to defend against?
For example: are you trying to protect against an attacker who is specifically targeting you and knows your system for generating passwords? Or are you just one of millions of users in some leaked database? Are you defending against GPU based password cracking or just a weak web server? Are you on a host infected with malware[1]?
I think you should assume the attacker knows your exact method of generating passwords and is just targeting you.[2] The xkcd comic assumes in both examples that all the details of the generation are known.
The Math
The mathematics in the xkcd comic is correct, and it's not going to change.
For passwords I need to type and remember I use a python script that generates xkcd style passwords that are truly random. I have a dictionary of 2^11 (2048) common, easy to spell, English words. I could give the full source code and a copy of my list of words to an attacker, there are still going to be 2^44 possible passwords.
As the comic says:

1000 Guesses / Sec
Plausible attack on a weak remote web service. Yes, cracking a stolen hash is faster, but it's not what the average user should worry about.

That strikes a nice balance between easy to remember and difficult to crack.
What if we tried more power?
Sure 2^44 is ok, but GPU cracking is fast, and it's only going to get faster. Hashcat could crack a weak hash[3] of that size in a number of days, not years. Also, I have hundreds of passwords to remember. Even xkcd style it gets hard after a few.
This is where password managers come in, I like KeePass but there are many others that are basically the same. Then you can generate just one longer xkcd pass-phrase that you can memorize (say 10 words). Then you create a unique 128-bit truly random password for each account (hex or base 64 are good). 128-bits is going to be strong enough for a long time. If you want to be paranoid go larger, it's no extra work to generate 256-bit of hex passwords.

[1] This is where the memory thing comes in, if you're on a compromised host you have lost. It doesn't matter if you type it or use a program like KeePass to copy and paste it if an attacker can key-log / read memory.
[2] Rather than the weaker (but more likely) assumption that the attacker has just torrented a dictionary called "Top Passw0rdz 4realz 111!".
[3] Sure we should all be using PBKDF2, etc... but lots of sites are still on SHA1. (and they are the good ones)


Is this Bash code vulnerable to code injection?

There are two quick observation:

Using eval is very dangerous and your variable ${command} is not efficiently sanitized. (They could contain backticks, period, control chars, etc)
Using bash for sensible operation is not recommended as they suffer from a lot of vulnerabilities. I recommend using poor shell (like dash), for critical scripts. (Or more evolved languages like Python or Perl).
Sample of unexpected behaviour:

/path/to/silently Blah "'echo `date`;return 1'"
Blah: Wed Oct 16 08:26:16 CEST 2019

Where command between backticks are executed, semicolons do command separation (as usual) and return 1 force mainFunction to consider the result as an error then print them.

By using the code you've published @gitlab.com, result of this look like:

/path/to/silently Blah "'echo `date`;return 1'"
silently: surplus arguments on: Blah 'echo Thu Oct 17 13:54:36 CEST 2019;return 1'
Note that command must be quoted

date command is executed and result shown as error text.

Then you could try:

/path/to/silently Blah "'echo `cat /etc/passwd`;return 1'"

Using bash to do sensible operation is something possible, but do require strong experience. I personally  recomand to not do that!


Does MITM attack work across Remote Systems?

It depends on what type of MitM attack you're working with.

ARP Poisoning - This only works when you have an Ethernet connection on the LAN, since it works by spoofing identities using OSI Layer 2 technologies, ARP MAC-to-IP bindings.  This seems to be the type of attack you are familiar with.
BGP Redirection - This works on the Internet since it involves affecting IP routes in the IP routing protocol, Border Gateway Protocol.  In this case, you can get other autonomous systems (groups of networks in the world) to think your router hosts the true path to a segment.  See this article with several historical examples.
Other attacks not exploiting weaknesses in a protocol - It is considered a "Man in the Middle" when traffic is intercepted while in transit.  This could involve application weaknesses, altered DNS settings, etc.  Some of these may work only on an intranet, others on a global scale.


OpenSSL issues this error because the root cert is not in the location that it is expects it. The default directory for this (tested only my debian wheezy machine) is  /etc/ssl/certs.

Hope this helps.


Android/iOS application security testing checklist

There is a project called OASAM that aims to define a methodology to test Android devices.

You can find it here: http://oasam.org/en

The guide has the following sections:

OASAM-INFO:  Information Gathering:  Information gathering and attack surface definition.
OASAM-CONF: Configuration and Deploy Management: Configuration and deploy assessment.
OASAM-AUTH: Authentication: Authentication assessment.
OASAM-CRYPT:  Cryptography: Cryptography use assessment.
OASAM-LEAK: Information Leak: Confidential information leak assessment.
OASAM-DV: Data Validation:User entry management assessment.
OASAM-IS: Intent Spoofing: Intent reception management assessment.
OASAM-UIR: Unauthorized Intent Receipt:Intent resolution assessment.
OASAM-BL Business Logic: Application business logic assessment.


Is there a method to decrypt *.p7m file without key?

Theoretically, you could brute-force it. Decryption will take somewhere between "immediate" and "The end of the universe", so it depends on how lucky you are.

Practically, no. It's not going to happen.


Backing up sensitive data - pitfalls and best practices

The biggest gotcha I encounter is still "did you test that you can recover from the backups?" I apologise if I'm teaching grandmother to suck eggs, but I still come across companies that happily write all their data out somewhere and never find out whether they can read it back.


Can a malicious add-on access internet history and other sensitive info in Chrome/Firefox?

Modern browser extensions use the WebExtensions API, which enforces a permission model; basically, addons can only have the access that you grant them (you can't reject individual permissions though; if you are uncomfortable with some, you can't install the addon).

Regarding your specific questions:

The browser history can only be requested if the history permission is granted.
The cookies permission only works along with a host permission which will define which cookies can be accessed. Host permissions are required for all of the sensitive actions (such as injecting JavaScript into a page, reading the contents of a page, etc).

Malicious extensions can of course execute arbitrary JavaScript in an isolated context, so something like a malicious cryptominer is certainly feasible.

For access which doesn't require explicit permissions, see my related question: Danger of browser extension without any permissions?.


Can CDN contents be decrypted by officials in new Telegram security design?

First, AES-256-CTR (as labeled on one of the squares) is in fact a symmetric cipher. No assumption required.

A more important aspect of this scheme is really preventing the CDN from changing files in an undetected manner.

The link between the client and Telegram server is presumably trusted, and information to verify the legitimacy of files in the CDN is transferred (ie. key and hash). If the CDN changes files, the trusted hashes will no longer match the malicious files.

This CDN scheme is only used for publicly shared files on Telegram, so the file can be considered to be at least quasi-public. The CDN host might obtain the key using Telegram which would also allow them to re-encrypt the file, but there is still no way for them to make the hash of the modified file match.


Why wouldn't it be great, if HTTP/2 would only allow communication via TLS?

Mandatory SSL/TLS for everything has the following drawbacks:

All systems must pay the cost of the cryptography. The cost is mostly negligible for current systems, except for the really small embedded devices, that would not be happy with that (but they are happy with unprotected plain HTTP).
SSL makes some caching strategies more difficult; in particular, transparent proxies no longer work. Some people (in particular Internet Service Providers) are quite fond of transparent proxying, because it helps them save on their own bandwidth.
In a non-SSL world, many sysadmins run filters and antivirus software on their exit routers / firewalls, and have grown quite fond of that practice. Switching to a whole-SSL network would require them to review their procedures and update their skills; of course they will fight such changes to their death.
Using TLS implies using X.509 certificates, and sending some money to one of the "commercial PKI" -- or configuring and maintaining one yourself, for private applications. Doing something is necessary (you don't get security out of nothing) but some people would prefer a model closer to SSH, without dirtying their fingers with the handling of the dreadful X.509 thingies.

Therefore it is expected that there will be some resistance to mandatory TLS. On the other hand, this is completely neutral for professional spy agencies, since their targets of choice already use SSL or similar protection mechanisms, even if they are not mandatory.

Developers of Firefox and Chrome have already announced that they won't support any kind of HTTP/2 that does not run over TLS; this is a deliberate pledge to try to overcome the pockets of resistance described above.


I'm not an expert on this but here is how I understand it:
A) The short answer, "something you know" does not have to be present for WebAuthn to work. That falls into securing HSM-Harware Security Module (or any other Authenticator that supports WebAuthn). WebAuthn is not about that, at least in this stage.  HSM vendors can incorporate security features to protect their devices in case of physical access (biometric spoofing, copying etc) or phishing. That will be dependent on the need of the users on how much security they need (corporate IT admin vs. average home user). I'm sure FIDO will certify different level of devices for different needs, and maybe some companies will require HSM with certain feature-set, and maybe in the future the industry will move to a more secure option. After 20+ years, we're now seeing HTTPS replacing HTTP at a rapid pace for example. It's a start and work in-progress in my opinion.
Also, biometric data only unlocks access to HSM / Authenticator (i.e Windows, iOS) and it doesn't give anything else about the private keys stored. Spoofing biometric can only be done when having access to HSM and that falls into securing the device. This is versus someone hacking a company and dumping everyone's passwords. With WebAuthn, the credentials obtained are useless. (But they can replace your public key there with theirs and can have access to your account depending on how the web app' security is designed - still much less damaging than passwords being traded in dark-web). If you replace the public-private key method with just sending the biometric data to web apps, it is the same as having a very strong passwords but unfortunately, the same password and irreplaceable ( you can't change your own biometric like a password) in every web app you use. This brings a privacy issue (web app knows your biometric and they can abuse it), second you give it to everywhere (it makes it a single-password for all - once compromised it's over). Also, similar to passwords, if they can dump these biometrics, they can sell / access your account just like passwords, just harder to crack (like a very strong password)
The way WebAuthn securely do this is through asymmetric key pairs (similar to how SSL works today - only generated by user's device instead of a CA like GoDaddy): The keys are generated per web app on the HSM, the private key stays at the user's HSM and the public key is passed to the web service and the web service stores & uses it in the future to decrypt the requests coming for your account. What is signed/encrypted by private key can only be opened by the public key so the web app knows that the request is signed/encrypted by the same private key originally registered. Since the keys are per web app, phishing through spoofing another web app's login screen is not possible.
This takes away the burden of managing / remembering passwords from the end user. It, also, eliminates weak passwords, case of re-using across multiple sites, passwords on post-it, passwords being phished, etc. What's left is securing the authenticator (HSM or laptop, iphone, yubikey, etc.)
Here is how the W3C specs describes this. As you can see, "something you know" is not required at this point:
"Authenticators are responsible for ensuring that no operation is performed without user consent"
"User consent means the user agrees with what they are being asked, i.e., it encompasses reading and understanding prompts. An authorization gesture is a ceremony component often employed to indicate user consent."
"An authorization gesture is a physical interaction performed by a user with an authenticator as part of a ceremony, such as registration or authentication. By making such an authorization gesture, a user provides consent for (i.e., authorizes) a ceremony to proceed. This MAY involve user verification if the employed authenticator is capable, or it MAY involve a simple test of user presence."
"A test of user presence is a simple form of authorization gesture and technical process where a user interacts with an authenticator by (typically) simply touching it (other modalities may also exist), yielding a Boolean result. Note that this does not constitute user verification because a user presence test, by definition, is not capable of biometric recognition, nor does it involve the presentation of a shared secret such as a password or PIN."
You can read more here. Start from the abstract and follow from there
https://www.w3.org/TR/webauthn/
B) If there is a Min-In-The-Middle (MITM) actor present before you register to a service and they are able see / modify your communication with a web-site, they can already own your account and after WebAuthn registration, they can continue to own your account by replacing your public key with their public key at the time of registration. But this is only possible if MITM can read clear text communication between the parties (i.e. already spoofing SSL between the parties). At this level, no solution through the same channel (i.e. web) will help. I don't think this is a problem or a shortcoming of WebAuthn itself as it's not its job to overcome a well-established MITM. A second factor authentication could help with this but if the same MITM has compromised that too, the result is the same. There is no perfect solution to this problem, even if the web app requires on-site in-person registration (i.e. con man, fake ids, etc.)


This is a very bad idea, but yes, various aggregators do exactly this. One of the few upsides of the new Open Banking and PSD2 regulations will mean aggregators are no longer going to need this sort of nonsense, as banks will provide APIs to share data.

It does present a huge challenge around understanding where data loss may have occurred after an incident, but for the customer there is a massive increase in security in not putting all these username and password combinations in aggregators database.


Alternative to storing passwords when dealing with integrations that only allow username/password authentication?

You should store the passwords encrypted with a modern symmetric encryption algorithm. AES with a 256-bit key is recommended. Be sure to use a well-known and verified implementation of AES. The key must be stored securely as it is used to both encrypt and decrypt the stored passwords.

Also, if the service you're authenticating to requires you to send plaintext passwords over a network, make sure you're using a TLS-secure protocol (e.g. HTTPS).

If the service doesn't support TLS connections, all bets are off and you should seriously consider how useful this service really is (imagine all of the other things they're doing insecurely. Do you pay for this service? I wonder how they store your billing information?).


How do I prove my proxy is scanning for viruses?

You can't really prove it, without going through proxy lo gs, antivirus logs etc., but you can certainly get confidence that it is by sending some test messages through with the EICAR signatures in it (see http://www.eicar.org/anti_virus_test_file.htm).

You can then see whether it flags them.


Why do we need OMEMO if XMPP is already encrypted?

TLS (Transport Layer Security) simply encrypts the data in transit between two endpoints.  This is good for preventing casual observation, but doesn't protect the data from all vectors.  And TLS is between two parties, so a group chat would need a number of TLS connections with the associated encryption overhead (direct chat); or would not be secure (relay server chat) as you are only encrypting to a relay server that could read the entire conversation (necessary in order for it to forward the conversation to the other parties).

OMEMO is actual message encryption.  And, perhaps more importantly, it is a double-ratchet system designed for multi-party communications with the security maintained even if a client is offline and waiting for delayed delivery.

Think of TLS like an armoured car.  You put your private message in the armoured car and it is secure from outside parties snooping in, but anyone involved in the armoured car company can look in the back of the truck and see what you put back there.  And (a special case for messaging) if no one is at the destination when the armoured car gets there, the guards give up and burn the message.

OMEMO is like if you have a favorite book cypher that you use to write the message.  Even if the armoured truck driver looks at the note, he still won't be able to read it.  And since it is [payload] encrypted the truck driver can leave the message on the recipients door step, and it'll remain secured.


It will always vary depending on the application and implementation, however some of the ways in which these applications function can be quite effective at slowing down malicious users, and preventing breaking out of the Kiosk interface.

At the end of the day, physical access will always prevail with sufficient time and resources.

Kiosk countermeasures:

Whitelisting - processes, dialogs, windows
Process watching - checking running processes,
terminating unknown and relaunching the kiosk app if it ends
Restrict execution of .exe's
Disabling commmon hotkeys and shortcuts
Disabling host functionality - e.g. Task Manager in Windows
Reducing underlying attack surface by removing unrequired software and applications, such as Java libraries
Restrict locations users can access, e.g. sites/domains in a web browser to only local or specified hosts. This could be implemented at a network/NAC layer rather than on the Kiosk host.

Possible Kiosk attacks will vary depending on the product and deployment in question, but some general ideas:

As you mentioned, bypass executable restrictions by launching through batch files (commonly restricted as well), flash, java, macros.
Where the user is restricted to a specific graphical application (e.g. browser), it may be possible to crash the browser through known vulnerabilities, such as in flash player.
Exploring gaps in restrictions for underlying host functionality, such as in IE Kiosk mode: (1) Save File/Target As, (2) Default Feeds in History, (3) Print to file, (4) New tab, link to help pages, (5) help functionality may allow launching of apps and services.

During a recent pentest on Internet Explorer in Kiosk mode I found this resource useful which references the iKAT Kiosk Attack Tool (note: NSFW image on iKAT page).


They're referring to short key IDs, which are considered vulnerable to collision attacks for quite some time now. The problem is already referenced in RFC 4880, OpenPGP,
3.3. Key IDs:

  A Key ID is an eight-octet scalar that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique.

OpenPGP Fingerprints and Key IDs

Each OpenPGP key has a fingerprint attached, calculated mainly from its public key packet which also contains the creation time. The calculation is defined in RFC 4880, OpenPGP, 12.2. Key IDs and Fingerprints.

There are short and long key IDs, which resemble the lower 32 respective 64 bits of the fingerprint. For example, looking at the IDs of my OpenPGP key:

fingerprint: 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279
long id:                                    4E1F 799A A4FF 2279
short id:                                             A4FF 2279

Fingerprints and key IDs are used, as sharing and comparing a whole key with usually 1024 to 8096 bits (adding some more for headers like the creation date) is very impractical.

Collision Probability

While shorter IDs are easier to share and compare, they also increase the chance of collisions. This is growing exponentially with the lenght, in numbers. This is the number of possible key IDs for each length:

2^32  =                                        4294967296
2^64  =                              18446744073709551616
2^160 = 1461501637330902918203684832716283019655932542976

The collision probability is the inverse of the numbers, being the chance of generating two different keys having the same ID.

Finding collisions for all publicly available OpenPGP key data requires finding collisions for barely 4 million keys. The project actually limited itself to the strong set (which contains the largest set of keys, that are all linked together, possibly with transient edges), and this currently contains about 55.000 keys.

Key collisions are still possible for long key IDs and fingerprints, but unlikely to very unlikely. The number of possible fingerprints is even larger than the number of possible UUIDs and these are usually expected to be unique. The same number of IPv6-adresses is available, techtarget.com has some examples to get an impression of numbers that large.

Enumerating Keys

Generating keys with reasonable security takes some time, making it impractical to enumerate enough keys to find those four million collisions. But that's why I already mentioned the key generation time above: with a single key, you can create lots of different OpenPGP keys from a single (lets say, RSA) key without the expensive key generation, you simply iterate over the time. This was already proposed by Micah Lee in his Talk on "Trolling the Web of Trust".

Regarding the UNIX timestamp to be stored as a 32 bit number, and assuming SHA-1 as a good hash function has nearly equal distribution of result values, iterating of a single RSA key with different timestamps should suffice to generate all possible short key IDs (in reality, you will have to repeat this for a number of keys). If you want to only generate reasonable keys created within some reasonable time span (say, the last few years, definitely not before PGP was released and not in the future) you will have to use some more keys, but generating some more keys is still doable in a rather short time.

What to do now?

Don't trust short key IDs, never use them for verification. You never should've done.
Use long key IDs instead (or even better, the whole fingerprint), if you want to share your key. To be very sure at verifying a key, better even compare the full fingerprint.
If you're developing software that deals with OpenPGP keys, even refer to the whole fingerprint (a computer doesn't really care about whether to compare 32, 64 or 160 bits, but remember the collision probabilities!).
Check your own software on whether it follows these recommendations.


Why is this certificate for Imgur only valid for one day?

This isn't one of Imgur certificates.

Certificate Transparency logs

Certificate Authorities must report all certificates they generate to transparency logs, which are public databases. This allows user-agents, like Chrome, to check that this certificate can be audited by the website's owner.

According to the following certificate transparency search tools, this certificate was not logged, and such a short lifetime is not usual for Imgur:

crt.sh
Google
Facebook

DNS Filter

According to the error messages, this certificate hasn't been issued by a valid certificate authority, so you can't trust the issuer.

The issuer claims to be "DNSFilter".

DNSFilter is a proxy used to filter requests, and it also tries to proxy HTTPS requests, so it generates a self-signed certificate for every domain.

Since you can't trust the issuer, you can't be sure that the certificate comes from the real DNSFilter product. Anyone could be impersonating it.

It's safe to assume that this is not a legit certificate for Imgur.

The exact reason for such a short lifetime for the certificate is unknown.


How to give someone access to a file, on a website, securely without relying on a single password?

The canonical answer would be — using cryptographic tokens.  In some countries or organisations, such tokens or ID cards may already have been issued and widely available.

But given the context, you should probably consider alternative delivery mechanisms.  For example, an automated nightly email to a librarian, with the newly added relevant entries in it, does not need introducing any new authentication mechanisms, has a fairly limited — and generally well-understood — maintenance expense and attack profile, meshes well with many modern styles of office routine, and has only one moving part that can be directly nudged by an attacker from the website end.  You should consider if the email needs to be encrypted or not, and which fields are relevant in its context, of course.


vulnerabilities in a machine that detects vulnerability scanners

Is there any vulnerability that a hacker might use to gain the command shell of the system?

That depends upon whether any of the software on your system is vulnerable.  We probably cannot answer that for you, and in any case, any answer would be too specific to your particular system to be of relevance to others and too limited in time to be of broad interest.

If you are unable to scan your machine with nmap, I suggest you check whether you have a firewall set up that might be blocking nmap.

For information about how to secure your server, I suggest you search on server hardening on this site.  I think you'll find a good bit of information about how to lock down a server to reduce the likelihood of vulnerability.

P.S. Generally speaking, I would turn off fingerd or configure my firewall to block all connections to it.  Almost no one uses finger these days, so there is not much reason to be running an Internet-facing fingerd server -- it's just unnecessary risk.


How to implement canaries to prevent buffer overflows?

Usually it's the compiler who generates canaries. Prologue and epilogue aren't function calls, they're the instructions the compiler places at the beginning and end of a function.

Consider a naive compiler which puts variables on the stack in the same order they appear in the code and doesn't use registers. Then your function might become:

// variables on stack
int c;
int d;
char *buffer[40];
int canary;

// prologue
canary = secret;

// normal code
c=a;
d=b;
strcpy(stupidcopy);

// epilogue
if(canary != secret)
    OhNoesABufferOverflow();
return;

You can't write this code yourself since compilers can and do optimize storage on the stack. They can reorder variables, keep them in registers and it could even optimize out canary entirely since no well-behaved code will ever trigger the condition.


How to access SQL server inside a Powershell script

If an attacker gains access to the server, you'll likely have other concerns than exposing clear text credentials in a file.

Also, your on the right track for inquiring about security best practices. Don't go through all of this effort only to email the results. Email is not secure so your results should be encrypted or use something else such as your mention of SFTP.

With that said, you have two options:

Windows Account - run the task as a dedicated Windows account and use Integrated Auth. This will not require storing the username/password in the connection string but you will need to store the credentials when setting up the scheduled task. If this account is compromised, you now need to consider what access it has. Either domain account or a local account on the sql server. If the former, they'll be able to enumerate domain resources and if the later access will be limited to the sql server. Finally be careful what security groups this account is granted membership, if any.

SQL Account - will be specific to the MSSQL instance though it will require storing the username/password combination in the connection string. A way to get around this is set NTFS permissions only allowing the account running the scheduled task access. For example, if the task runs as SYSTEM only allow that account access to your script. Don't forget to include the account used to run backups and your account as well.

DPAPI - I believe this would be out-of-scope for what you're looking to accomplish so I'll just mention that DPAPI allows one to use asymmetric encryption in configuration files and such.

Consider account management when making your choice. There may be policies requiring a password change every ?? days. See what applies and choose the account type that best fits what you're looking to achieve.

No matter what option you choose, make sure the account only has access to run the applicable stored procedure(s). This will limit the exposure on your sql server should the account become compromised.

Finally, there are lots of examples of using PowerShell to run stored procedures. I just used the following search string which returned lots of results.

  sql server stored procedure from powershell stackoverflow


How to guarantee privacy on files that I store

One further step is to use a key derivation function to derive a key from the user's password.  You can then encrypt the data key used for encrypting each file with the user's derived key and you can store the encrypted form of the data key on your server with the file.  Without the user's password the key can't be used, but it also lets the user access it from multiple devices without having to deal with key management.


Does the telecom provider need physical access to the SIM card to clone it?

No, telecom providers do not need physical access to the SIM.

They can change the allocated number or any SIM unique ID, therefore they can:

assign the number to any new SIM and unassign it from the old one (this is actually a standard procedure for anyone losing their phone/sim)
clone the number to any SIM

References- cellphone operator sites:

https://www.att.com/esupport/article.html#!/wireless/KM1081808
https://support.t-mobile.com/thread/140087
https://www.verizonwireless.com/support/4g-sim-card-faqs/
https://forums.att.com/t5/Wireless-Account/Replace-a-lost-SIM-via-mail/td-p/4879263

Third-party articles with more detailed explanation:

https://www.reddit.com/r/verizon/comments/7797iw/how_can_i_replace_a_lost_sim_card/
https://www.techwalla.com/articles/how-to-activate-a-new-att-sim-with-the-same-phone-number
https://www.phonenomena.com.au/blog/2015/01/29/how-to-transfer-your-mobile-number-to-a-new-sim-card/


Encryption of instructions to and from satellites in space

Probably not applicable to newer stuff, but historically I think it was big dish and complex custom protocols rather than encryption that "protected" satellite communications.  Consider the case of an older satellite that NASA allowed amateurs to try and connect to, and the obstacles they faced and overcame:

How to talk to a 36-year-old Space Probe

As the primary link is now offline, some relevant snippets:

  Actually, one of the most difficult parts of this project was sifting
  through hundreds and hundreds of pages of specifications from NASA.

  ...

  Now that we had a system that was capable of transmitting correct
  commands to ISEE-3, we had a little bit of guess work to do. There
  were a number uncertainties about the behavior of the space craft
  receiver. Ambiguous specifications on items like receive lock range,
  phase modulation index, and mark/space tones, left us with some
  uncertainties to deal with. Also, a rough link budget showed that we
  should have about 5 dB of margin under ideal circumstances. If we had
  any significant pointing errors, or there were other factors we hadn’t
  accounted for, there was a decent chance that we were operation near
  the best sensitivity of the space craft receiver. This meant we could
  have a marginal link with frequent bit errors.


Why Nessus freezes at 0% and how to fix it?

A couple of things to look at.

Try a basic scan of one machine on the same subnet as you, if that hangs for a long time it could be a problem with the system that's doing the scanning or the install of Nessus
Are you running from the VMWare appliance?  If you are check the networking on that.  If you run nessus over a network card in NAT mode it will go very slowly and may not complete at all.  Bridged mode is the best one to use for that.
as @D3C4FF says how long is it hanging for?  depending on the number of hosts and network connectivity to them it can take a while to get going.
Lastly if you've not already, try posting on the Tenable security forums, they're usually pretty responsive over there and if it's a specific nessus problem they may well be best placed to solve it.


Tools for reverse engineering malicious executables?

Tools exist that can disassemble an executable most of the time, but it's not guaranteed. There are many techniques used by malware to resist analysis that prevent tools from providing a clear picture of what's going on, without significant manual intervention.

The first level of these are Packers which essentially create proxies for calls to obscure what procedures are doing and often encrypt data.

More advanced techniques serve to prevent analysis in tools like IDA by changing execution depending on whether it's being run in a real system or a debugger. Here's a good rundown of Packers, crypters, and anti analysis techniques.

You may want to check out the reverse engineering stack exchange.


Is HTTPS redirecting to HTTP a vulnerability?

In terms of browsing security/privacy, any time you are over http, your traffic could be (and often is, see cache discussion below) intercepted and fiddled with by servers along the way.  Period.  You can't be sure if the page you see over an http connection is in fact the page that the webserver sent in response to your web client's request.

As far as session hijacking, the answer is a bit more complicated.  The concern would be that you type your username and password over an https connection, and the server then sets a cookie on your browser that identifies you.  That cookie will be sent back to the server by your browser with each subsequent request for pages, and the server will thus know that it is you asking for the pages.  The concern is that somebody along the way was listening and copied that cookie.  They could then send requests to the same website using your cookie, and the site would think it was you.

The Set-Cookie header has a secure flag (see here) which can be turned on when the cookie is originally given to your browser.  If this flag is set, the web client will not send the cookie back to the originating domain except over an https connection.

It would be possible for a site to, say, have two authentication cookies, one of which is marked secure.  That way, anytime you want to do something really sensitive you are required to have the secure cookie, and are thus redirected to an https page.

In that case, the site designers have to make a per-page decision as to what is "really sensitive" and what is not.  The scope for "oops" is enormous.  This is one reason why https all the way is preferred.  There are reasons why this is not done by all sites:

(Probably the biggest reason): Many networks (your ISP potentially) maintain a cache server that watches traffic leaving their network.  If it sees that you are trying to retrieve content (all the little pictures & icons on a popular page for example) that other people have recently retrieved, it will give you a cached version.  There is all kinds of support for this: the original site has a way to indicate what can and cannot be cached, and for how long.  All this is good for the ISP and the original site, since it means that they both have less bandwith crossing into/out of their networks.  Https breaks this, as the proxy now has no idea what you are asking the original site for.
(no longer a problem) There is computational overhead to setting up a secure connection to a site for the first time.  This used to be a problem for a server accepting lots https connections.  This problem is largely gone now - there are several mitigating protocol factors, as well as acceleration hardware and other methods that have basically fixed this problem.  I only mention this in case you hear that https puts a heavy computational load on the server: AFAIK that is no longer true.


Vicious circle with certificates - how to trust the server cert?

Update in response to your edits in the question
You are correct that validating a cert up to the trusted root is not 100% foolproof. What it guarantees that a trusted CA issued this cert to the domain that you are communicating with (because you can check that the URL in the cert matches the URL that you are establishing the SSL connection with). This was how SSL was designed to work. If that's not good enough and you don't fully trust the CAs in the Android trust store, then there are still things you can do.
It sounds like what you are describing is Certificate Pinning. Here is a guide to certificate pinning by OWASP, which even has a section about Android. The idea is that you include either the public key or a hash of the full certificate of the root CA, intermediate CA, or server cert in the source code of your app. Since all Android apps get code-signed at build-time, you can be confident that the "pinned" public key will arrive at the device un-tampered. Unless the device is rooted (more on that below), you should be confident that it will remain un-tampered.
It's good that you're thinking about this very carefully. That's good. But, as @Limit said,

I think you are overthinking your problem :)

You are not the first person to think about this problem, and there are standard ways to solve it. You are making things much more complicated by trying to invent your own solution. A chain of signatures leading back to a cert in the OS trust store (or a pinned key if you want to go the extra mile) really is enough to guarantee that the certificate is real.

About rooted devices, you said:

nova days [now a days] even EPROMS are writable ???? if you can write into memory there is no such thing like immutability :)
besides rooted device is vulnerable for fs files altering

If your app is running on a rooted device (either rooted intentionally by the user, or by malware) then all guarantees and security proofs are off. There are some tricks you can do, but they are security theater at best. As far as real security goes, it's game over. I'm sorry but you're just going to have to accept that, unless you want to enter into an arms race with rootkit authors - which is well outside the scope of this site.
I also want to point out that while possible, the attack you're alluding to is very advanced. You can add code to your app to check the integrity of the binary against the code-signing signature, and refuse to run if the check fails. Here are some links from a quick google search:

Android Security: Adding Tampering Detection to Your App
Retrieve the apk signature at runtime for Android

With root access to the device, it is possible for a hacker to remove this check from your binary, but this will not happen from casual drive-by malware. It requires expert hackers to spend weeks reverse engineering your app. The kind of experts that you only find in government spy agencies and organized crime. It's time to define your threat model: are you worried that your app will be attacked by nation-states or organized crime? Yes / No?

No: then don't worry about it, doing certificate pinning and a runtime self-test of the code-signing will protect you even on rooted devices.

Yes: then stop getting advice from random people on the internet and go hire a real security consultant!

Your use-case seems a little strange. It sounds like you are trying to re-invent SSL, rather than using SSL the way it was designed.
In SSL, the server always presents a certificate to prove that it is the right server. The point of mutually-authenticated SSL (where both the server and the client have certificates) is for the device to prove to the server that it is the right device. Having the server send the client a key to decrypt the client cert is a bit like having the server prove to itself that it is the right server. ??

How does the client trust the server's certificate?
The client should trust the server's certificate only if it chains back to a root CA cert that is in the Java Keystore. If your server's certificate was issued by a public CA (ie you bought it from Digicert, or Verisign, etc) then the root should already be in the Android keystore. If it was issued by a private CA, then the right thing to do is to include the root CA's certificate in the app resources and add it to the Java Keystore on the app's first run. (This is safe because the app .apk is code signed, so the cert can not be modified.)
All of this should be handled automatically by Android's SSL libraries. If you are getting exceptions about not trusting the server's certificate, then try adding the root CA cert to the Android trust store.
Inventing your own method of establishing trust by having the server send a decryption key is almost certainly wrong, and is almost certainly more work.

For more reading, please see:
How does SSL/TLS work?
(I know it's a lot of text, but it is a very good reference)


When using AES and CBC, can the IV be a hash of the plaintext?

A hash computed over the plaintext would have the right characteristics for an IV, as far as "uniform randomness" is concerned. This is for a cryptographically secure hash function, not a CRC. Rather, something like SHA-256. A CRC is in no way secure enough for cryptography.

However, the IV must be known to whoever will decrypt, so it must be stored along the encrypted message. If the IV is computed with a hash function from the plaintext, then this allows performing a dictionary attack on the plaintext (trying possible plaintext until one which matches the hash is found). Defeating dictionary attacks is already hard enough for passwords, which are meant to be secure and random-looking; so, for something as utterly non-random as a display name, you should really use an IV generated from a properly secure cryptographic random number generator, not a hash computed from the plaintext. It will not change your storage costs, since the IV must be stored anyway, regardless of how you generate it.


How to strike a balance between security policies and practical implementation challenges?

Since this question is not a technical one, rather more about human behaviour, you won't get the answer. What you describe is very typical though and I made the same experience.

Complex password rules will usually not lead to more safe passwords, really important is only a minimum length, and a check against a list of the most used passwords. People cannot remember tons of strong passwords, and such rules can even interfere with good password schemes. People can get very inventive to bypass such rules, e.g. by using weak passwords like "Password-2018", which satisfies most rules. Often you end up with weaker passwords instead of stronger ones.

The same applies to the password-change rule, it is very common to add an increasing number or the current month to the password.

Recently NIST published an official paper (see chapter 10.2.1), advising against such rules, and against its former recommendations.

A try to answer the edited question:

We can try to delegate authentication, either with single-sign-on
or with OAuth2, this way we can reduce the passwords a user has
to remember (same password for multiple services).
One could recommend a password-manager. A link on the login page to a good tool won't hurt.
We could engourage password-phrases. Why not place a funny example on the login page: "I like to sleep until it is too late to get up", this raises awareness and shows the user how much easier (and mobile-friendly) pass-phrases can be. Just make sure to reject this exact example.


The suitability of blowfish as a cipher and bcrypt as a password hash are mostly unrelated. There are many better replacements for blowfish, but not so much for bcrypt.

Blowfish is mostly discouraged because it has a better replacement in AES, not because it's broken. AES has seen a lot of analysis, during and since the competition. Another problem with blowfish is its 64-bit blocksize, which leads to relatively small limits on how much data can be encrypted using one key, whereas AES uses 128-bit blocks and can thus safely handle larger amounts of data. It also has some annoying properties, such as a slow key-setup and relatively high memory use.

PBKDF2-HMAC-SHA-1/2/3 is significantly weaker than bcrypt, so I'd only choose it if you need standard compliance or if your language only ships it but not bcrypt by default. The underlying hashes may be secure, but that doesn't make it a good password hash.

As a modern replacement for bcrypt, the only currently feasible candidate is scrypt. It offers improved security, but it's relatively new, not very popular, and hasn't seen much analysis. It hasn't been included in many standard libraries yet either. So more conservative cryptographers will prefer bcrypt over scrypt.

A competition to find a new password hash resulted in a few interesting alternatives, such as its winner Argon. But I don't consider these suitable for production for another five years or so. Perhaps in 2020 we might have a similar opinion of bcrypt as we have of blowfish now, but we're not there yet. For now bcrypt is a good choice if you're conservative, or scrypt if you're progressive.


TKIP is deprecated since 2010, and practical attacks exists against it. You should not use it. Since you do not have devices that requires it, you have no reason to leave it activated and all the reasons to disable it. I suggest you look into your range extender manual for how to configure it.


Organization like OWASP for network security?

If you're looking for the equivalent of OWASP for network security then I'd suggest that testing methodologies like OSSTMM or PTES (although PTES is still rather incomplete), are a good place to look for information.

However as you say both of those will have a very large amount of information in them.  This is really because network security is a less well-defined proposition when compared to web application security.  It spans a wide range of topics (Unix OS security, Windows OS security, network devices, databases etc) so the range of checks needed to complete a thorough review is going to be a lot wider that it will for a single web application.

That said if you're looking for a basic set of checks for network security I'd recommend.

Port scanning of all hosts in the target networks to establish what services they offer
Vulnerability scanning of the open ports using a tool like Nessus or OpenVAS.  Vulnerability scanners have a huge number of pre-programmed checks for common security issues so they're a good way to identify basic issues. Also if you provide credentials for them to authenticate to your servers they can do a more thorough job of checking things like patch levels
In addition to this I'd recommend checking all management interfaces for default credentials.  This is a very common issue and one that is the cause of a lot of breaches. Doing this can be as simple as connecting to each one and trying common default combinations (e.g. admin/admin).  You can also review documentation for the system under review to see if it mentions default accounts (they often do)

Whilst doing this won't find all the issues in a network, it's a good first step and if you can resolve all the issues raised from this sort of scan your network would be heading in the right direction from a security standpoint.