Password and Login verse very long string (token) I'm building a PHP login system that uses a username and password at first to grant the user a token and uses that token to grant the user access to their account.

My original thought was to force the access_token to refresh often, closing the window for potential brute force attacks.

However, after thinking it over, I realize that the access_token may be more secure than a username and password...

If I have a username of 24 characters, and a password of 24 characters, won't a 128 character access_token still be more secure? Let's assume all are using alphanumeric characters.

Edit

It seems that the above statement was a bit veg. I'll be a bit more specific.

Scenarios

Example A

I have one system with a 24 character alphanumeric username and a 24 character alphanumerics password.

Example B

I have another system with a 128 character alphanumeric token.

Question

If two computers set out to brute force both systems, which system would most likely take the longest?

If you were to judge purely based on character size and wanted to compare a 24 character username and 24 character password system vs a 128 character token system, I would say that the search space would be larger in the token based system.

Obviously, to brute-force a username/password combination, the user needs to find a pair in two n^24 search spaces while in the there are several elements in the n^128 sized token search space that will be valid tokens. As a result, it can happen that your brute-force system does find a token before it can find a valid username/password pair. But finding all valid username/password pairs will take less time than finding all valid tokens.


Does AWS KMS use HSM underneath by default? Have a doubt about about how AWS KMS handles their asymmetrical/symmetrical keys. Does AWS KMS use Hardware Security Modules (HSMs) underneath by default? (cant find documentation that prove/dissmiss the fact).

I saw that it is possible to create a custom key store and connect to your dedicated HSM in the cloud (AWS HSM). However, AWS HSM is expensive and low level. If AWS KMS already by default handled its keys in an HSM, it would bring a huge cost reduction. Saw that Google Cloud KMS does exactly this (you can choose HSM as protection level) and you pay per key usage.

Is it possible to have something similar to Google Cloud KMS in AWS?

AWS KMS FAQ states that by default HSMs are used for Customer Managed Keys (CMK). Other option is to use AWS's CloudHSM as you have mentioned in the question.

  The key material for a CMK is generated within hardware security modules (HSMs) managed by AWS KMS. You can also have the key material generated and used in an AWS CloudHSM cluster as a part of the custom key store feature in AWS KMS


poodle attack/padding oracle attack According to wikipedia or https://www.us-cert.gov/ncas/alerts/TA14-290A

this is an issue with the SSL v3.0 non deterministic padding used in CBC.
Is AES in CBC mode itself is un-secure or it is an issue only when used in SSLv3.0/TLS ? Can you please clarify ?

I use openssl (an old version before the poodle attack fix) aes-128-cbc mode to encrypt a file like below, openssl enc -aes-128-cbc -in test -out test.enc -K $key128 -iv $iv

Is test.enc secure as far as the poodle attack/padding oracle attack is concerned ? If not secure, how can I make it secure ? will patching openssl to the new version take care ?

Thanks

POODLE requires a MITM component to be successful. You need to have a long enough stream of cyphertexts before you are able to decypher the stream. Encrypting a single file does not expose MITM vectors.


Failure on correct credentials with the consecutive success? The idea to "improve" security is as follows - the service will reply with a failure code even if supplied credentials are correct, but then on a second (third/whatever configured) attempt it will return a success and provide an auth token.

The rationale behind it is that even if there was a leak of some hashes/passwords - then the service will return a failure code to the "hackers" making them think that the password/hash they've stolen isn't valid.

One obvious flaw here as I see it is the overall increase in communication time due to retries, but the service in question isn't the one under high load, so that probably can be ignored.

Are there indeed any benefits here? Or is there any harm in this approach?

Outside of the obvious flaws in that it will increase communication overhead and that it will piss off users, how long do you think it will take before everyone realizes what's going on? My guess is somewhere between immediately and almost immediately.

And once it's known that your service is rejecting the first login attempt, what stops hackers from just running each hacked password twice? Or thrice?


Apache Partial HTTP Request Denial of Service Vulnerability One of our client scan our site and share following qualys vulnerability.

"Apache Partial HTTP Request Denial of Service Vulnerability - Zero Day "

We are using "Ubuntu 12.04.5 LTS" with Apache/2.2.22. We have implemented lots of options, mentioned is this url
Its CVE is CVE-2007-6750

But every scan find this vulnerability.

What we should do now?

This is the slow loris attack of incomplete HTTP GET Requests.

How to protect your server: Update your Apache Server, there are many updates for this attack, this attack was discovered in like 2011. Other options are to reduce timeout on your Apache Server, etc. This attack works on timeout. Here tells you how to protect your Apache from DoS/DDoS (slow loris included) on Linux (provides updates, shows settings to be changed).

What is the slow loris? The slow loris is a layer 7 Denial of Server (DoS, can be carried out with 1 computer) that is used widely on Apache servers and more, because these servers if not updated have this "bug".

How does the slow loris work? The slow loris is done by a TCP connection being made, and then an incomplete HTTP GET request is sent to the server. The server then does not timeout this connection for long periods of time as high as 400 seconds. The server (such as Apache server's) do this because the idea is, it thinks you are on some untrusted network, or simply slow internet and will wait for the rest of the HTTP GET Request.

More Information: This is an HTTP DoS not a TCP DoS because the request is what is causing this. A slow loris attack can work at sending 1 packet per second for each new connection.

Examples of how this request looks like:

GET / HTTP/1.1\r\nHost: www.whatever.com\r\nUser-Agent: Mozilla 5.0\r\n

or

GET / HTTP/1.1\r\nHost: www.whatever.com\r\nUser-Agent: Mozilla 5.0

Example of normal HTTP GET Request:

GET / HTTP/1.1\r\nHost: www.whatever.com\r\nUser-Agent: Mozilla 5.0\r\n\r\n


Is password information dumped from the MySQL user table sensitive? Assume I have dumped MySQL user list using

SELECT user, host, password, ssl_type FROM mysql.user;

The result looks like this:

+------------------+-----------+-------------------------------------------+----------+
| user             | host      | password                                  | ssl_type |
+------------------+-----------+-------------------------------------------+----------+
| admin            | %         | *blablablablablablablablablablablablablaa | ANY      |
+------------------+-----------+-------------------------------------------+----------+

Should this information be considered sensitive? Can an attacker use the password information to access the MySQL database? It seems the password is hashed, therefore it is not directly usable, but perhaps it can be still exploited somehow, e.g. to help creating rainbow tables for my server, or something like this?

Yes, it's sensitive information. It's a password hash leak.

Attackers will supply this information to a bruteforce application (there are some tailored just for MySQL) and retrieve the password.

Not only this, but the % on the host field means that if your MySQL port (3306 by default) is not firewalled, the attacker can access it as admin from anywhere.

Consider locking the admin account just for localhost, and never disclose a password hash, no matter how confident you are on the difficulty of breaking such hash.


PHP encrypt and decrypt with certificate I am trying to think of the best way to encrypt and decrypt a message between two servers. I have found a lot of examples where people simply use a secret and PHP's mcrypt...
https://stackoverflow.com/questions/16600708/php-string-encrypt-and-decrypt
But I am thinking of using certificates instead.
https://stackoverflow.com/questions/7480681/crypt-decrypt-string-php
Am I wrong in my assumtion that it would be more safe? Or is it pretty much the same deal? With certificates you need to get to the private key on the receiving end... with the string version you need some access to the code on one of the two ends to get a hold of it.
And whould the crypto be more safe using certificates? Like creating a 2048-bit RSA.
Thanks.

Generally speaking, asymmetrical encryption is safer than symmetrical because remote end can only decrypt data, with no possibility to encrypt. The key is only useful for decrypt, server encrypt with a different unpublished key.

Even with self signed certificates, in my opinion security is enhanced comparing to symmetrical encryptions solutions. Go for it.


What happens if my private key gets stolen in the web of trust? If I'm a trusted user in the web-of-trust but my private key gets stolen by Eve, how would other users find out that my key is compromised and thus cannot be trusted anymore? Is there a way for them to find out and revoke the key?

You can publish the revocation certificate. Ideally, you should've generated a revocation certificate while you generated the key pair, so that you can still revoke even if you later lose access to the private key. If not, you can generate the revocation certificate as long as you have access to the private key.

When you publish a revocation certificate, your users have to download the revocation certificate before they'd notice that your key should no longer be trusted. They can do this by syncing their keyring with the key server where you've published your revocation certificate.


xp_cmdshell to add domain admin Did an assessment on SQL injection the other day and the only question I didn't do was to add an domain admin. Got access to xp_cmdshell. Tried net user username password /ADD /DOMAIN but permission denied

SQL Server 2008 R2 and Windows Server 2008 R2

Any pointers? I have the domain name and the list of administrators if that helps?

This is by default disabled on those particular versions. For your exploit to work your database user would need access to the xp_configure command to enable the xp_cmdshell after which you can actually add your user.


Infect an existing Android app with malware and redistribute Is it possible to someone de-compile an Android apk of a legitimate application and inject a malicious code, recompile and distribute?  Our company's IT people deployed some apps into our mobile phones (BYOD) and I am bit concerned about it.

Possible yes, but it would not install as the same app. Also most (all?) apps on Google Play are signed with a certificate with vouches for authenticity.

An example:
They take the official YouTube-App, modify it and replace the real YouTube-App on your device with their fake. In Google Play, the app will show as "Not installed" and you may install the real one parallel to the fake one. The reason is the different signature and maybe different package names.


Is it possible to run Meterpreter command in background After spawning a meterpreter session from the target Windows 7 system I wanted to search for all the files with sub-string "clue" in in their name. As search -f "*clue*" took a long time to complete, I found it a waste of time. I want to know if it's possible to make it a background task somehow and get the meterpreter prompt back?

I tried my luck with Google but it only shows results for Meterpreter's background command which sends the entire session to background and gives us the msf prompt.

Here are three ideas to consider:

Use bgrun with search_dwld.rb
Use file_collector.rb
Create your own script

bgrun

The best solution I can find for this is to use the command bgrun. As the Metasploit script states,

  "bgrun" => "Executes a meterpreter script as a background thread"

Bgrun executes a script in a background thread, however the search command can't be used with bgrun. The closest script I can find to the search command is search_dwld. Search_dwld works in a similar way to search and also downloads the files that have been found.

The usage for search_dwld is as follows:

  search_dwld -- recursively search for and download files matching a
  given pattern

  USAGE: run search_dwld [base directory] [filter] [pattern]

  filter can be a defined pattern or 'free', in which case pattern must
  be given

  Defined patterns:

  $filters.keys.sort.collect{|k|"\t#{k}"}.join("\n")

  Examples:   run search_dwld

  => recursively look for (MS|Open)Office in C:\

  run search_dwld %USERPROFILE% win9x

  => recursively look for *.PWL files in the user home directory

  run search_dwld E:\\ free '.(jpg|png|gif)$'

  => recursively look for pictures in the E: drive

You can use search_dwld with bgrun like this:

bgrun search_dwld

File Collector

Another option is the file_collector script. As the link above states,

  Meterpreter Script for searching and downloading files that match a
  specific pattern. First save files to a file, edit and use that same
  file to download the choosen files.

file_collector is a three part process. First we create the file list, then we remove any files we don't want from the list, then we execute the download process. Here is a guide on how to use file_collector.

You can also use file_collector with bgrun as stated earlier with search_dwld:

bgrun file_collector

Create script

Another alternative is to make your own script in Ruby which searches for files.

bgrun searchScript.rb

This could actually be a good solution as you can make the script fit your exact needs.


Self-Signed Certificates with SSL Today I was playing around with an SslStream implementation in C#, and was able to create a client/server connection over TCP. Also to verify it, I used wireshark to ensure that the data was in fact encrypted, but I have a couple of questions.
First, I should explain the process I went through.

Create a TCP client with an SslStream layer inside. The TCP client connects to the server and DOES NOT try to authenticate the servers identify (just returns true when validating the server certificate). Once connected, just send a simple message to the server
Create a TCP server with an SslStream layer inside. The server uses an X509 certificate that I generated with powershell (see this post from MSDN if interested)
Install the certificate on my server computer's Personal Certificates (which requires me entering the password for the private key that was generated). The server listens, connects to the incoming connection, and prints out the decrypted data on screen.

Now, my question is basically this. What I've set up above, is this essentially a secure connection (e.g. both server and client have the symmetric key and encrypt/decrypt at will), but both are unable to verify "who" is on either end? For example, the client can't be sure of the server's identity, and the server can't be sure of the client's identity. Is this the case?
I want to use this scheme in a IOT project to control a garage door with a smartphone app.
So, my question is leading to another question: if I have my smartphone app (client) establish the SSL connection with my server, and then enter a password in my smartphone app which my server can verify (I guess I could use SHA-2 to hash the password on both ends, but is there any point since the channel is secure?), wouldn't this be able to verify the client from the server's perspective? Am I missing anything here?
Thanks.

For example, the client can't be sure of the server's identity, and the server can't be sure of the client's identity. Is this the case?

Correct. But validating the server certificates only addresses the first point: that the client is not sure about the servers identity, i.e. that the client might actually be connected to some man in the middle attacker instead who is able to sniff and modify the traffic.
Client identity is typically addressed inside the application protocol (i.e. login with username and password) but can also be addressed inside TLS with client certificates.

... then enter a password in my smartphone app which my server can verify ...  wouldn't this be able to verify the client from the server's perspective?

Yes, this identifies the client against the server. But as long as the server certificate is not checked it might still be that a man in the middle attacker can intercept the connection and just claim to be the server against the client and claim to be the client against the server - then forward, analyse and potentially modify the data between real client and real server. And the attacker could also sniff the password this way and use it later again to impersonate the real client, without the real client being involved at all. In case of the garage door this would mean that the attacker could control the door even if the owner of the garage is not present.
Using a client certificate would protect against this attack even if the server is not authenticated by the client with a certificate - as long as the server checks that the client certificate is the expected one.


Security requirements for one time access code/token in the url I have an application that will send an SMS reminder for user containing a URL to log on. I would like to avoid user typing in username/password and log him in directly. For that I plan to use an access token and add it to the url, e.g:

www.mydomain.com?token=JFPIENBFIOHGDFGP3423432

Now since that is an SMS, I cannot hide it behind the "a" tag. So I would like to limit the length of the token as much as possible not to scare users too much. Perhaps also limit the symbols to only capital letters or something or some other way of "beautifying" it.

Is this is a proper approach to do it and if yes, then what security should be applied to the token. As far as I can see I need this:

Generate the token using CSPRNG
Make sure it's enough entropy (my application does not deal with very sensitive info, so I suppose say 32 bits should be enough, maybe even less as the username/password is just phone/digital pin code)
Make sure that the token is one-time and/or short lived (e.g 24 hours)

That's certainly a reasonable approach.  I would, as you suggest in your post, limit it both to a token that is both time-bound and one-time-use.

How long it needs to be depends on how much entropy you feel you need to introduce.  If you were to beautify it by just using uppercase characters and numbers, that given you a character space of 36 characters.   An 8 character token, chosen completely randomly from this space will have ~41.36 bits of entropy.  This is not enough for a password, but could be potentially usable as a token. Depending on how many are issued, and how many attempts to validate them your application supports, this might not give you enough margin for safety, however.   A 12 character, completely randomly generated token would offer you around 62 bits of entropy, and if you wanted to go to 16 characters, you would be getting into password-quality strength, with over 82 bits of entropy.

So, it's definitely a workable scheme with good randomness, and the length of the tokens depends primarily on how much safety margin you want.  8 characters is marginally workable, 12 characters is probably a pretty reasonable sweet spot, 16 if you value security more than compactness.


Can the human brain generate cryptographically secure random numbers? A security conscious friend of mine was attempting to generate entropy using random dice rolls to generate a random password, and I became curious about the security of random number generators and whether or not she could do the same by simply thinking of random dice rolls. Would it compromise the security of password/key generation to use human-generated random numbers instead of random numbers from a dice or a secure random number generator?

I can see how the standard random number generators included in many programming languages might not be cryptographically secure in known and exploitable ways, but how about the random numbers generated by the brain? When I asked her, she stated that humans were terrible at generating entropy, but I'm not sure that this is the case. How do humans rank in the generation of key entropy and would it be possible for a human mind to take the place of random number generator for key/password generation without being exploitable?

It's plausible that entropy could somehow be generated from brain processes, but doing it directly (e.g., "think of a random number") is, in my opinion, pretty easy to discount.

In a random sequence of bits, the value of any given bit is independent of all other bits in the sequence. However, if you ask a person to generate a random sequence of bits, there's no way to isolate the generation of a bit from the knowledge of which bits preceded it.


Close XSS vulnerability I run a vulnerability  scanner on my website which showed me a couple of vulnerabilities which look like this:

http://.../search?text=&ClassIDNames[37]=<script>alert('Found')</script>&ActiveFacet[ClassID]=37

but when copying the url to the browser it does not give me the alert output but the search result for the corresponding input.
Is this anything I have to fix or is it nothing to worry about? Or do I have to do anything else to reproduce it somehow?

Some scanners simply search for the injected string ("found" in this case) somewhere on the page, if "found" is in the search results, then it would classify it as a positive finding.

If the XSS string is being interpreted as a string in the search function (literally searching for the string <script>alert('Found')</script>, then you can chalk it up as a false positive - the scanner saw its own injected string in the resulting page.


What does txpower exactly means? I stumbled upon a guide which says increase txpower by setting region to some place. So my doubt is
1.What does txpower means?
2.What if if increased txpower will there be any trouble?
I am saying txpower of my wireless adapter.

TXpower(transmission power) is the strength of the router's signal. If you are looking to reach a wider range, you configure the txpower to a higher setting in the router's settings.

One of the main concerns is security; a wider signal range is heard by more neighbors. If any of them is malicious and your router lacks proper encryption, you would be susceptible to malicious attacks. Hence why people suggest to leave the txpower at the default setting where it is only available to you; unless of course you have a viable reason to change it.


Should you notify software vendors that their software has been cracked? Apologies if this is not the right place to ask this question, I will happily move it to another Stack Exchange site if need be.

Before I explain the rationale behind the question, let me clear up a few things first.

I enjoy cracking software, for my own educational purposes.
I do not participate or work for any cracking group.
I never release or publicize any cracks/keygens and do not use them for personal gain.
I attempt to protect my own software better based on flaws I discover in other people's software.
I am a software vendor myself and would hate for my work to be pirated, so I gladly pay for licenses and would appreciate if anyone ever approached me and pointed out flaws in my software.

With that out of the way, my question is, if I am able to successfully crack a piece of software (games, components, etc.) should I notify the vendor that their software is vulnerable, or just keep it to myself?

I have notified a few people/companies (usually small time developers) in the past of which all appreciated the feedback and subsequently strengthened their license checking as a result. Should I be doing this on a regular basis or can I get into serious trouble for even attempting to reverse engineer something? I don't charge or try blackmail people either, totally above board with full disclosure.

My own EULA states "Redistribution of source code is strictly prohibited by means of reverse engineering or otherwise" which clearly highlights redistribution, not personal gain or even self improvement (no idea, I'm not a lawyer).

This moral dilemma has bugged me for quite sometime and I would love to report back to vendors so that they can avoid being compromised. Not sure if everyone will be forthcoming about it and may even be offended.

All software vendors know their software can, and always will be cracked.  Software has been cracked for as long as there's been licensing or copy protection.  Cracking groups go back to the 1980s, and copy protection schemes went as far as punching physical holes in a specific sector in floppy disks.  That sector could never be written to on the original disk, and so if it an attempt was made to write to it, and it worked, you knew the software had been copied.  This was cracked, and the software copied and distributed across the country on BBSs.  Every software protection and licensing scheme that's been tried has been cracked.  Software licensing isn't meant to be 100% secure, it's meant to keep honest people honest.  That's it.

Should you tell them?  If you care about the software in question and want it to improve more, probably not.  Either one of two things will happen.  The vendor will (quite rightfully) ignore it.  Or someone at the company will have the idea that the protection needs to be "fixed" because someone has defeated it.  Needless effort will then be expended to create yet-another-protection-scheme, and the cycle will continue.

Either way, you're either wasting your own time reporting it, or the software developers time in "fixing" the cracked software.

By all means keep cracking software. It's an interesting game to play, and many have enjoyed jumping the fence just for the challenge.  But don't be under any illusions that you've found some critical flaw, that if someone just fixes, it'll be unbreakable again.


What are specific use cases for anonymity? There are various technologies for anonymity online, most notably TOR, but also I2P and VPNs, as well as simply using one-shot email addresses.

What are the specific use cases for anonymity? I'm not concerned about the morality or legality of the use cases, but I do want specific cases. So "selling contraband online" would be ok, but "doing illegal stuff" would not be specific.

Some ideas to get you started:

Whistleblowing, where the whistleblower doesn't trust the authority they are reporting to.
Discussing personal issues in public forums (e.g. drug addiction rehab).
Selling contraband online

This question was inspired by LamonteCristo's question.

I start off by giving general cases, but then use specific examples for each case.

Protecting Personal Information:

Virtual Private Networks ("VPNs") and proxies are most commonly used to encrypt traffic and hide one's IP address.

There are two main reasons why others would want to use them:

To access or use a service that would not normally be available to them

Example: Jonas lives in Germany and wants to watch a music video on YouTube.  However, when Jonas clicks on the video, YouTube displays a message that the video is only available in certain countries because of copyright issues.  To watch the video, Jonas connects to YouTube through a proxy server located in America.

To prevent others from recording their actual IP address (a legitimate concern at times, not always paranoia or to get away with cyber crime)

Example: John is a married man, but he is not so faithful...  He uses Ashley Madison to find friends (if you would call them that).  John used a random alias and email when he signed up, but he also only connects to the website through a VPN.  When John learned that Ashley Madison got hacked, he was not so scared.

Check out this CBS article on data brokers, it does a decent job of explaining how the personal information that you use to sign-up on various websites and services is sold.

You can easily avoid having your personal information sold by simply using fake information when signing up.  Just make sure that you are using fake information, not valid information that actually belongs to someone, even if it is a stranger.

Using TOR or I2P:

While many use TOR and I2P to help protect personal information and to safely browse the internet (myself included), a good number of TOR and I2P users are cyber-criminals.  We can use TOR/I2P "illegal" marketplaces as an example.  In theory, criminals can buy and sell items such as 0day exploits, credit card numbers, weapons, and drugs while remaining anonymous using Bitcoin.  Law enforcement cannot find hidden service IP addresses without using some type of exploit.  If they were to gain access to the hidden service, they would most likely just shut it down because unmasking it's users could prove to be a difficult task.

Using Numerous Random Emails:

As far as using "one-shot" email addresses, it is not really that bad of an idea.  Here is a great example of why it is, in fact, a good idea.

Alice uses one, main email for everything she does including but not limited to social media, paying bills, receiving transcripts of tax returns, sending scans of personally identifiable items such as her social security number and driver license, and online shopping.  She used an extremely, insecure password while signing up and never bothered to change it.  Not to mention, Alice never deletes her emails.  Her email is eventually compromised after five years of use, and the attacker now at least knows the following about Alice: full name, date of birth, address records, phone records, mother's maiden name, social security number, federal ID, state ID, driver license number, driver license issue date, driver license expiration date, private social media messages (private and direct messages), full credit card numbers along with their expiration dates (Amazon shows you the credit card issuer, last 4 digits, and expiration date while a credit reports shows you everything except the last 4 digits) , and everything that was in Alice's "sent" folder.  Alice now has a huge mess to clean up.

This could be avoided by making an email for each type of online activity.

Bob does a lot online, in fact, he does everything that Alice does (paying bills, shopping, and receiving important documents in his inbox).  However, there are quite a few differences between them.  Bob uses five different emails while Alice only uses one.  Instead of using an insecure, single password, Bob uses a different, secure, randomly generated password for each email.  He writes the passwords down in a notebook, so that he does not forget them.  Bob also deletes all emails that receives, if he needs to save something, he downloads the email/attachment or writes the important information down in a notebook.  Even if an attacker did somehow gain access to one of Bob's emails, they would not find anything because Bob is smart and deletes his emails.


https: Is my company connection intercepted? I wanted to find out whether my company can see what I'm posting online as soon as using websites using a valid https certificate.

I know there are a lot of posts here about whether my company can find out which URLs I've visited. Now I wanted to find out whether I'm being intercepted by the proxy-server we use (we have a computer-wide proxy-server in place which is also used for webbrowsing) by means of "faked" https-certificate.

IMHO my company doesn't use such a procedure, but I just wanted to confirm it by some experts on here.

When I'm browser to https://security.stackexchange.com on my companys laptop in firefox, the certificate-hirarchy looks completely identical to the certificate-hirarchy showing in Chrome on my home computer:

Even the certificate fingerprints and serial-numbers are completely the same.

Is my understanding correct that:

Even though we are using a proxy, it is sufficient to check the certificate hierarchy and when it's the same inside the companys network and in my home network, I can conclude I'm not being sniffed the inputs I do
The procedure of the proxy-server to "insert" a faked https-certificate, in case there would be such a system in-place, would probably be made system-wide. That means, as I only compared the certificate-hierarchies on a few domains now, it should mean such a procedure will highly likely not be in-place at all, also not for any other domain?
That means the only way to track my inputs, would be to use some sort of keyloggers? (Which is probably not possible / allowed by law anyhow (living in germany)).
From what I gathered from the other posts here on stackexchange, they can obviously save from the logs which URLs/hostnames I have visited. They question is: Do they see the full URLs or only the hostname / the target server? Because it could potentially do a big difference whether I visited some reddit page about how to setup some software or some reddit page about po*rn :D Obviously I won't visit these, just frmo a technical POV I want to know what's possible here.

Thanks in advance!

Even though we are using a proxy, it is sufficient to check the certificate hierarchy and when it's the same inside the companys network and in my home network, I can conclude I'm not being sniffed the inputs I do

You can conclude that you are not sniffed for this specific site and this specific time only.

  The procedure of the proxy-server to "insert" a faked https-certificate, in case there would be such a system in-place, would probably be made system-wide. That means, as I only compared the certificate-hierarchies on a few domains now, it should mean such a procedure will highly likely not be in-place at all, also not for any other domain?

It is possible to intercept only selected sites or only at specific times or only specific clients (based on ClientHello fingerprint) or to explicitly not intercept some sites. Thus it is not possible to conclude from one site not being intercept that other sites will not get intercepted too or even that the same site gets not intercepted at another time or with another client. You might check if you find some unusual root certificates in your certificate store but these are not that obvious to detect.

  That means the only way to track my inputs, would be to use some sort of keyloggers? (Which is probably not possible / allowed by law anyhow (living in germany)).

There are several ways to monitor users apart from keyloggers and HTTPS interception. For example browser plugins could be used or simply the whole system could be mirrored similar to  remote desktop software.

  From what I gathered from the other posts here on stackexchange, they can obviously save from the logs which URLs/hostnames I have visited. They question is: Do they see the full URLs or only the hostname / the target server? Because it could potentially do a big difference whether I visited some reddit page about how to setup some software or some reddit page about po*rn :D Obviously I won't visit these, just from a technical POV I want to know what's possible here.

Only the domain is known and not the full URL. See Are URLs viewed during HTTPS transactions to one or more websites from a single IP distinguishable?.


Does changing an image src attribute to call a PHP function on my server to retrieve an image from another server eliminate CORS policy issues? I am working in React, and I have an image which has an src attribute of https://s3.amazonaws.com/sample_endpoint. My website domain is https://sample-website.com.

I am using a library, dom-to-image, https://www.npmjs.com/package/dom-to-image-more, which takes any html element and converts all of its children elements to an image.

The base element I am using has this image mentioned above inside of it. When I use the library, it gives me the following:

  Access to image at 'https://s3.amazonaws.com/sample_endpoint' from origin 'https://sample-website.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Unfortunately, there are no options with this library to set the Access-Control-Allow-Origin header. That's why I wanted to try out this option but I'm not sure if this eliminates the CORS issue.

Approach:

Change the src attribute of the image from a hardcoded s3 server url to a PHP function call. This would mean that the PHP code running on https://sample-website.com is requesting the resource, therefore being on the same domain and avoiding the CORS policy issue.

So, before it would be: src="https://s3.amazonaws.com/sample_endpoint"

and now: src="getImages()"

where getImages() sends an HTTP request to the backend at some endpoint.

Will this get around the CORS policy issue?

Using your PHP server to proxy the request to the S3 server will indeed help you to solve that CORS issue, since your webpage and the image will be on the same origin.


How can ECDSA offer stronger security with the same key length (same amount of entropy)? It's always been told that ECDSA is more secure "per bit of key size", such that it offers same security with a shorter key, or offers stronger security with the same key length.

However, per my understanding, if the length of the key is fixed, it means that the amount of entropy is also fixed (e.g. 160-bit ECDSA key contains no more entropy than 2^160, and a 192-bit AES key contains no more entropy than 2^192). So why is ECDSA considered "more secure" at the same level of entropy?

ECDSA is an asymmetric digital signature algorithm based on Elliptic Curve Cryptography (ECC), closer in purpose and function to digital signatures using RSA.  Both are asymmetric algorithms that are very different than AES, which is a symmetric encryption algorithm.

The comparison you are talking about is most likely comparing ECC key sizes to RSA key sizes.  This is where the math differs.  ECC’s strength is based on the difficulty of solving the discrete logarithm problem.

RSA's strength is based on the difficulty of factoring the product of two very large prime numbers.

The comparison of the two must take into account the difficulty of the math, not of the simple count of the bits.

AES, being symmetric, is completely different.  A brute force attack on AES simply consists of trying every possible key in the 2^128 space.

For more information on key lengths, check out https://www.keylength.com, which has an interesting set of comparisons of key lengths taking into account historic, modern, and predicted futures.


Logging requirement in PCI DSS for in house application Recently we had an PCI Gap assessment, and the auditor asked as to show the application log, but we had very basic application log that only stores events and any exception. But auditor told us that transaction request & response log must be stored, Now we can do that but doing so will store card details (Which are encrypted) which we want to avoid as we don't want to store any card details. So what i want to know that it is required by the PCI that we must store the request post body, even if it contains encrypted card details?

Sorry if i have asked this question in wrong place but i didn't know any other place to ask such question, Thank You.

[is it] required by the PCI that we must store the request post body,
  even if it contains encrypted card details?

No, there is no PCI DSS requirement that you store incoming request POST body.  In fact, while there's an entire section of the DSS (§10) dedicated to logging, it concerns itself with system and security logging, not transactional logging.

Transactional logging is mentioned largely in §3, mostly to prohibit storage of  unencrypted sensitive data (track, CVV, PIN, ...) in transaction logs.

I think your auditor has a reasonable point that you need transactional logging, but that need not include raw request or response data.  You should be logging things like time, source, internal transaction lookup, and response (as in, "success" or "failure", not response body).

These sorts of logs support normal business processes such as, "Hey, IP 1.2.3.4 submitted a fraudulent transaction at 12:34:56; tell me how many transactions they made that day and whether they were successful or not."


Why is firefox attempting to direct me to a Captive Portal, when I'm connected to my own router? I am connected to my own router, and I know for a fact that I do not have a captive portal installed. Firefox displays a banner at the top of the page saying that "you must log in to this network before you can access the Internet.", with a button that says "Open Network Login Page" to its right.The link forwards to http://detectportal.firefox.com/success.txt. Notably only one machine is affected. Just sort of wondering what the possible reasons are for getting suddenly seeing this.

I also know that someone hasn't set up a fake router SSID- because I can see that I'm connected to the router via the router's web-config utility

The captive portal detection works by requesting http://detectportal.firefox.com/success.txt (or something similar) and seeing if the expected contents are returned. Possibly something on your router, or computer is altering the page, so Firefox is assuming that there is a captive portal in the way?


What are the risks of having a password policy on a domain that is not configured at all Id like to understand the risks more in depth to explain it to someone who has a password policy that is not configured at all.

I take it from your question you have a brand new Active Directory domain that has been set up with default password policy.  Presumably you also have default account lockout policy as well.

By default, passwords have an expiration of 42 days, a minimum length of 7, and must meet password complexity rules (e.g. cannot contain the user name, must contain any 3 of uppercase, lowercase, digit, special character, or symbol). These rules don't seem terrible, so leaving them at their defaults doesn't present an intolerable risk.

However, account lockout policy by default is disabled. This opens up your domain to brute force attacks, since a user can try as many passwords as they want for as long as they want. At a minimum you should turn this on, even to a somewhat high number (e.g. 20).


Are files hosted on cloud servers/websites/databases manually checked by people? I was wondering ... when I upload a file to, say, Dropbox, does anybody personally check it to see what it is?

Say I upload a copy of my Blu-ray movie to cloud storage ... will anyone check, and could they possibly tell law enforcement that I uploaded a digital copy online?

Or is it all 100% automated, and nobody actually looks at anything, leaving the process entirely to software and hardware with no human intervention?

Some guy told me that he stores tons of illegal movies, games, etc. online in cloud storage encrypted and nobody can find out what he has there since he encrypted it offline and then uploaded the encrypted block of data online.

If I were to upload copies of my movies (so that in case I lose the actual disks and not wanting to fill my hard disk up with so many gigabytes of data) online, should I be concerned with anyone checking the files one-by-one? Or am I thinking in the stone ages here?

Because IF nobody did check personally what's hosted on your cloud storage/etc., like Box.com where they don't even know where your files are hosted and nobody watches them/checks it, isn't this illegal haven? If nobody checks it,
you could have anything there as long as nothing calls for analyzing, correct?

Box.com claims that they host your data cross virtual servers, other companies' servers, etc. In that event your data is flowing around all over the place and nobody is actually "watching" or "checking" to see what you uploaded, meaning I could post, say, a video of someone I murdered (kidding) online and nobody without any lead would know this because the file would not be checked on their side.

PS: I don't mean "check" as in determine file format, etc. I mean check as in actually seeing what a file is, contains, such as viewing a photo, video, sound, text file, etc.

If files are encrypted and that encryption is done competently, then the contents cannot be inspected by third parties. Crucially, this requires (in your situation) that the encryption is done on your computer, with a key (or password) that you keep for yourself, and do not send to anybody else, in particular the people that host the file storage cloud system.

Of course, if the file name is "video-of-me-killing-colonel-Mustard-with-the-candlestick.encrypted" then a policeman with a pair of functioning neurons might get somehow suspicious about the file contents, even if the encryption prevents him from actually looking at the contents.

From a business point of view, it seems highly implausible that anybody checks file contents manually(*), on a general basis, on big cloud-based storage system. This would be astronomically too expensive. However, if you, personally, have shown up on the radar of a law enforcement agency, that may motivate them enough to (get a search warrant and) have a look at your files.

(*) However they may automatically look for files with byte-to-byte identical contents to known contents whose copy is legally restricted in some way. For instance, ISO images for the installation DVD of some software. It suffices to compute a hash on each file, and lookup the hash in some database of known hashes.


xp_cmdshell: should it ever be used? Can xp_cmdshell ever be used safely within a stored proc and are there any situations for which there really is no other option? In other words, should its usage within a stored proc always be flagged as a security issue (as is advised by a well-known source code analyzer)?

Put differently, would you agree with the following statement (direct quote)?

  The function xp_cmdshell cannot be used safely.  It should not be used.

Turning off xp_CmdShell is a bit like putting a veil over rotting meat. It brings a false sense of security to the table and the flies can still get at the meat. Allow me to explain.

Who can use xp_CmdShell? That's right. Only people/app logins with "SA" privs or people that you made the horrible mistake of granting a proxy to can use it.

Next question. If you have xp_CmdShell turned off, who are the only people that can turn it back on? Correct again! Only people/apps with "SA" privs can turn it back on.

So, what's the real issue with xp_CmdShell being a security risk? The answer is xp_CmdShell is NOT a security risk. Poor security is the only security risk. If a hacker or an malicious internal user get's into the system with "SA" privs, then they can turn xp_CmdShell on in momements. Yeah, that action gets logged but that only provides documented testimony that security was grossly lacking to begin with.

Turning xp_CmdShell off does nothing for security except to provide a chance for that part of a hackers code to turn it back on to run.

I'll say it again. xp_CmdShell is not a security risk. Only bad security is a security risk. Fix your security and then turn on xp_CmdShell. It's a wonderful tool and you're missing out on it because of bad security practices and myth.


Is my AES/CTR/RIPEMD encryption correctly implemented? Below is my encryption implementation in PHP. It's based on mcrypt, and uses AES-128 in CTR mode along with a RIPEMD-128 HMAC for integrity checking.

For brevity, I've inlined the functions for calculating HMAC, verifying HMACs, directly int encrypt/decrypt functions. On the other hand, I've added more comments below than the original code has, to ensure that what happens can be properly understood by people unfamiliar with PHP1.

function encrypt($data, $key, $hmac_key) {
  // Get the appropriate IV size for AES-128/CTR
  $ivSize = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, 'ctr');

  // Create a random IV.
  $iv = mcrypt_create_iv($ivSize, MCRYPT_RAND);

  // Encrypt with AES-128/CTR with the provided key.
  $encrypted = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $data, 'ctr', $iv);

  // Base HMAC on the contatenated IV, the encrypted data and the cipher identifier.
  $hmac_data = $iv . $encrypted . MCRYPT_RIJNDAEL_128;

  // Calculate HMAC using ripemd128 and the supplied HMAC key.
  $hmac = hash_hmac('ripemd128', $hmac_data, $hmac_key);

  // Concatenate together the IV, encrypted data, and hmac, and base 64 encode them.
  return base64_encode($iv . $encrypted . $hmac);
}

function decrypt($encrypted, $key, $hmac_key) {
  // Decode from base 64.
  $encrypted = base64_decode($encrypted);

  // Get the appropriate IV size for AES-128/CTR
  $ivSize = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, 'ctr');

  // Grab the IV and HMAC from the data.
  $iv = substr($encrypted, 0, $ivSize);
  $hmac = substr($encrypted, -32);

  // Cut out the remaining data, which is the cipher text.
  $encrypted = substr($encrypted, $ivSize, -32);

  // Base HMAC on the contatenated IV, the encrypted data and the cipher identifier.
  $hmac_data = $iv . $encrypted . MCRYPT_RIJNDAEL_128;

  // Calculate verification HMAC using ripemd128 and the supplied HMAC key.
  $verification_hmac = hash_hmac('ripemd128', $hmac_data, $hmac_key);

  $verification = true;
  // Refuse to proceed if the two HMACs are of different length.
  if (strlen($hmac) !== strlen($verification_hmac)) {
    return NULL;
  }

  // Always iterate over the entire length of the HMACs to avoid timing information.
  for($i = 0; $i < strlen($verification_hmac); $i++) {
    // Check for strict equality for each character.
    if($verification_hmac[$i] !== $verification_hmac[$i]) {
      $verification = false;
    }
  }

  // Refuse to proceed if the two HMACs don't match exactly.
  if (!$verification) {
    return NULL;
  }

  $decrypted = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, $encrypted, 'ctr', $iv);

  return $decrypted;
}

1: I'm thinking primarily of the concatenation operator, dot (.), which may not be entirely obvious.

Looks fine to me, except your use of RIPEMD128, about which Wikipedia has this to say:

  The 128-bit version was intended only as a drop-in replacement for the original RIPEMD, which was also 128-bit, and which had been found to have questionable security.

I suggest you choose a better hash for your authenticity, e.g. SHA256 or at least RIPEMD160.


How much information does an improperly obscured barcode leak? Often while sharing information on social media, some people may hide PII and yet still allow some aspect of a barcode to leak.

Question

Is there any research that describes how a damaged/obscured barcode can

Describe with certainty some information (Zipcode, but not address)
Reduce the amount of guessing one has to do to recover that information... where there is a fact table that is processed.  Any fact that ends in bits XYZ is a candidate for exposing PII

To directly answer your question, you can see some research on damaged QR codes here:  http://datagenetics.com/blog/november12013/

A barcode is nothing more than a specialized font designed so that a computer can read reliably.  It's much easier for a computer to recognize and read a pattern of stripes than it is for it to read Courier or Arial.  And just like the Latin alphabet symbols you're looking at right now, the symbols have to be readable to the machine.  Just as we all agree that the letter 'O' is represented to humans by an oval shape, barcodes follow standards that describe the meanings of the stripes and dots.

However, the text that is printed by the barcode is not nearly as standardized.  Some barcodes, like the familiar UPC and EAN barcodes, are strictly numbers that identify a product, and these do follow a standard.  But others, like QR-codes, allow free-form text.  A valid QR-code may contain a URL with a web link, or a vCard with contact information, or just some random words like "Have a nice day."

So there are as many different kinds of barcodes as there are kinds of text to input.  If you want to prevent online theft, treat pictures of barcodes the same way you would treat a picture of your credit card.  Do not include photos of personal documents showing these numbers or barcodes.  This includes event tickets, gift cards, driver's licenses, and airplane tickets.  Otherwise, an online thief may make a copy and steal the value from you.

To more specifically answer your question using this information, imagine a linear barcode with left half obscured.  This is the equivalent of obscuring the first half of a sentence or word printed on the page.  The right half remains legible, although it may not contain enough information to fully convey the message.

Now picture a 2D barcode, such as a QR-code.  Many 2D symbologies are designed to include redundancy permitting accurate reading of the barcode, even when parts of the barcode are obscured or damaged.  This is needed because damage to barcodes is very common in normal handling.  So when a QR-code is generated, you can specify a level from 1-4 of redundancy you need the code to embed. They use a Reed-Solomon algorithm to add more error recovery symbols.  More redundancy allows for a greater portion of the barcode to be damaged while still maintaining readability.


Connect Cables in pc and it’s affect Is there anyway I can know if the cable I use to charge my phone in it was connect to my pc before or not? Is there something in pc can let me see that because my pc contain some malware and spy files that comes to it through another phone because I used to use all cables and connect them to pc so I decided to format my other iphone in charger while charging it in the wall during deleting your data and setting the phone turned off so I connect it to the charger and it start to format and delete all data and settings while connect to charger so I format it again and I am afraid that the malware will be inside the iPhone system and even formatting it will no help

No, it is not possible to know the history of a cable (sad news).
But, good news, a charging cable cannot be used to propagate malware whatever its history (the malware can be inside the devices at each side of the cable but not INSIDE the cable)
An exception could be a specific gear, crafted by a hacker, to look like a charging cable but with some minimal computing capabilities (like this kind of gears whose take the appearance of common computer tools : https://shop.hak5.org/collections/sale/products/lan-turtle).
You can be confident with the fact that no one will use it against you until you start to store very sensitive data (like being employed at boeing) or have a hacker friend who like jokes.


Is it really safe to use Signal or Telegram on untrusted phone hardware? How safe are we when we use phone hardware from untrusted manufacturers and use end-to-end encrypted communication like Signal and Telegram? Are our conversations really safe from keyloggers or spyware? And what is the best option to communicate safely?

The short answer is that if the hardware is compromised, then anything you can read, it can read.


What is the difference between $200 and $1,000+ Firewalls? Instead of asking about the pros and cons of specific hardware, I thought I would ask a broader question: What are the differences between really expensive and inexpensive firewalls? What extra features/support will you typically get? And while firewalls (hardware) will need software to run, is it necessary to still use a standard OS' firewall?

It was suggested here (in scenario 3) that multiple firewalls are more beneficial to a larger company (500+ people). Is the reason just that the more firewalls you have, the more protected you will be?

  This question was IT Security Question of the Week.
  Read the Jan 6, 2012 blog entry for more details or submit your own Question of the Week.

One of the biggest and most important factors between firewall hardware is maximum throughput and typical latency. Low-cost firewall hardware usually has a maximum throughput of less than 100Mbit/sec even though the network adapters might theoretically support more than that. This means that the firewall becomes your network bottleneck in many scenarios. Determining the throughput of your firewall involves more than just looking at the port speed.

Processing data quickly requires fast CPUs, high-speed interconnects and plenty of fast RAM, and very high-quality network adapters. Just the hardware alone for a firewall capable of passing data at 1 Gbit/sec with minimal examination can put you up in the several hundred dollar range. Furthermore, the more examination you do on passing traffic, the more CPU power and memory you consume. Adding complex filtering logic will significantly increase the CPU and RAM utilization. And any resource exhaustion will result in delays or dropped packets.

Doing stateful packet inspection and particularly application-level protocol logic is possible even on a $60 home router, but the performance impact at high utilization would be severe.

The interface for your hardware is generally not a major expense, but since most people equate the quality of the interface with the quality of the hardware in general, companies with deep interest in the survival of their product generally will put some extra effort into making the interface easier to use. At least, that's the theory. Sometimes companies like Juniper and Cisco make me doubt that assumption.

Also bear in mind that some companies build an entire business around not only providing firewall hardware and software, but also in providing regular updates to the OS, the filtering rules, patterns for spam and malware, and so forth. If you want that kind of service, you have to help pay the salaries for the people who provide it.


How does CAPTCHA mitigate DDoS attacks? This seems like an easy question, but I've failed to find an answer.

One of the uses of CAPTCHA is to cope mitigate Denial of Service attacks. Suppose an adversary performs excessive login attempts, leaving other users unable to log in; the service can require solving a CAPTCHA before logging in. But why, in this case, does the CAPTCHA service continue to run while the login service fails under the same traffic load? Why does it work?

BY THE MAGICK POWER OF UNICORNS!!!

Snark aside, CAPTCHA is a very poor solution for D/DoS protection. While it does have some effect, this is minimal, and easily compensated for by the attackers.

CAPTCHA solves the wrong problem for this, and solves it badly.
CAPTCHA does not try to rate-limit the connections; it is not intended to protect the login mechanism from attacks; it is not possible for CAPTCHA to differentiate between attackers and legitimate users.

The only thing it does do - and not very well, at that - is, not surprisingly: Tell Computers and Humans Apart. This might in fact be useful to you, if you were in a Matrix-like reality, where all Computers are the enemy, and all Humans are allies.
In our reality, that is a pointless differentiation. Ostensibly, this might help with preventing scripted attacks - but even if this were true (it's not), there are plenty of ways to bypass that requirement - e.g. CAPTCHA proxies (where you need to solve a CAPTCHA before we show you dem pr0n) and CAPTCHA farms (where you hire some fareasterners to "solve" CAPTCHA for you, at 4$ per 1000 pops).
Moreover, in the case of DDoS - often this attack is mounted by "political movement" - i.e. large masses of humans decide to bring down a certain site. So yeah, CAPTCHA would be irrelevant here.

Besides all that, state-of-the-art CAPTCHA is far behind state-of-the-art OCR. If you want your users to easily decipher those squiggly images - the computer can do this too, pretty well. The best CAPTCHAs were measured at 20% OCR success rate - which effectively means that for every successful request, the attacker would simply need to send 5 requests. Not quite the order of magnitude that would make a substantial difference, to an attacker that is already planning on mounting a DDoS.

Some of my other posts here and on SO regarding this:

A good summary here on Sec.SE
Practical non-image based CAPTCHA approaches? on SO
Has reCaptcha been cracked / hacked / OCR'd / defeated / broken? on SO

TL;DR:
The question is based on a faulty assumption:

  How does CAPTCHA defend from DDoS attacks?

It doesn't.
At most it might require a bit more effort from the attacker, but not much.


If the cypher-text, plain-text and nonce is known, can the secret key be determined? I'm using the sodium_crypto_secretbox and sodium_crypto_secretbox_open functions in PHP (currently PHP 5.6, using paragonie/sodium_compat).

If a user has cypher text, nonce and decrypted plain text, can they determine the key that was used to encrypt the information?

The context: I'm encrypting the user's login token (a cookie, stored on the machine) and using this as a CSRF token. The CSRF token necessarily includes the nonce for decryption when submitted. The CSRF token is decrypted and verified on submission of form POSTs to protect against CSRF attacks.

My concern is not so much for CSRF attackers who won't have access to the cookies, but for the key itself. For simplicity, it would be useful to use the same key for other encryption functions in the software, but I can't if it can easily be exposed via this information. A legitimate user can see CSRF token and cookie: could they discover the key?

If a user has cypher text, nonce and decrypted plain text, can they determine the key that was used to encrypt the information?

Depending on the encryption algorithm used, knowledge of the plaintext and ciphertext does not reveal the key. Otherwise, a single block of known plaintext (a common header or an attacker-controlled value, for example) would break the cipher! Such a key-recovery attack is very rare for any modern, well-designed cipher. The library you are using supports several secure ciphers based on DJB's Salsa20 algorithm. All the ciphers used are secure from key-recovery attacks.

  For simplicity, it would be useful to use the same key for other encryption functions in the software

It is generally a very bad idea to re-use a key for any other purposes. Each distinct use of encryption should use a new key. For example, your CSRF token encryption key should not be the same as a link encryption key. If you really do have one key-sized value, you can expand it safely into multiple keys. A safe way to do this is with the popular HKDF function. You give the function one master key, and it spits out any number of cryptographically secure keys fit for use.


DNSCrypt-proxy: This certificate looks valid I have just installed dnscrypt-proxy and dnsmasq with DNSSEC but I get a strange message in the logfile from dnscrypt-proxy.

[INFO] + DNS Security Extensions are supported
[INFO] - [dnscrypt.eu-dk] does not support Namecoin domains
[INFO] + Provider supposedly doesn't keep logs
[NOTICE] Starting dnscrypt-proxy 1.6.0
[INFO] Generating a new session key pair
[INFO] Done
[INFO] Server certificate #808464433 received
[INFO] This certificate looks valid
[INFO] Chosen certificate #808464433 is valid from [2015-09-11] to [2016-09-10]
[INFO] Server key fingerprint is 164E:1AD6:4356:777D:2019:F2F9:D389:2DDB:BC75:8AF0:9172:8E0C:A874:10C7:3BE8:423B

The part that I think is suspicious, is this:

[INFO] This certificate looks valid

It sounds like the dnscrypt-proxy have doubts about how valid the certificate is. What happens to the absolute state of valid? Either it is a valid certificate or not.

Have I done something wrong with the configuration?

Configuration file (Resolver part):

DNSCRYPT_PROXY_PROVIDER_KEY=3748:5585:E3B9:D088:FD25:AD36:B037:01F5:520C:D648:9E9A:DD52:1457:4955:9F0A:9955
DNSCRYPT_PROXY_PROVIDER_NAME=2.dnscrypt-cert.resolver2.dnscrypt.eu
DNSCRYPT_PROXY_RESOLVER_ADDRESS=77.66.84.233:443
DNSCRYPT_PROXY_RESOLVER_NAME=dnscrypt.eu-dk

init.d script (start part):

if start_daemon -p "${DNSCRYPT_PROXY_PIDFILE}" ${DNSCRYPT_PROXY_BIN} \
    --pidfile "${DNSCRYPT_PROXY_PIDFILE}" \
    --daemonize \
    --ephemeral-keys \
    --user="${DNSCRYPT_PROXY_USER}" \
    --local-address="${DNSCRYPT_PROXY_LOCAL_ADDRESS}" \
    --provider-key="${DNSCRYPT_PROXY_PROVIDER_KEY}" \
    --provider-name="${DNSCRYPT_PROXY_PROVIDER_NAME}" \
    --resolver-name="${DNSCRYPT_PROXY_RESOLVER_NAME}" \
    --resolver-address="${DNSCRYPT_PROXY_RESOLVER_ADDRESS}" \
    --logfile="${DNSCRYPT_PROXY_LOG_FILE}" \
    $DNSCRYPT_PROXY_OPTIONS; then

The internal dataflow is as follow:

| DNS Client -> DNSMasq (+ DNSSEC) -> DNSCrypt-proxy | -> | LAN/Internet |
+----------------------------------------------------+----+--------------+
|                    Internal                        |    |    Network   |

It is valid.

See this change in the developement tree.

That said, your configuration should be simplified. When using a predefined resolver, all you need is the resolver name:

DNSCRYPT_PROXY_RESOLVER_NAME=dnscrypt.eu-dk

It doesn't make any sense to provide the name of a predefined resolver and then manually override everything. Worse, it will break if the certificate parameters change.

Just remove DNSCRYPT_PROXY_PROVIDER_KEY, DNSCRYPT_PROXY_PROVIDER_NAME and
DNSCRYPT_PROXY_RESOLVER_ADDRESS. These are only useful when you are running your own DNSCrypt server.


TLSv1 failure after receiving server certificate I'm running into a weird issue when trying to perform a TLS connection.

I know that my machine is not accepting the server certificate from looking at the wireshark logs.

This is telling me I dont trust the  CA that signed the server Certificate, but I have uploaded the Certificate that signed the Sever certificate into my Trusted Root Certificate Authority Store.

I have even downloaded the certificate that the server is sending me and examined the path of it to make sure it was trusted.  I can see under the Certificate status that the Certificate is OK.

I'm not exactly sure on why my client machine is refusing the connection from the server certificate.

There are many reasons why a TLS connection would fail other than Trust. From the screenshot you provided, it is not obvious that TLS negotiation failure is caused by "my machine is not accepting the server certificate". To determine exact trust issue you need to look into alerts (SSL Alert Messages) and see if it states bad certificate (code 42), unsupported certificate (43), certificate revoked (44), certificate expired (45), or certificate unknown (46). In Wireshark, this would look like Alert (Level: Fatal, Description: Bad Certificate).

Specifically, looking at the packet capture, the last message is Server Hello, Certificate, _Certificate Request_, Server Hello Done. This tells me that the server is configured to request mutual authentication. Therefore, the next expected response is Certificate Message from the client followed by Certificate Verify. I do not see that in your screenshot. Alternatively, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message as some clients are configured to ignore mutual authentication and server could be configured to allow such behavior.

I think the likely cause of handshake failure here is that your client does not support/is not configured for mutual certificate-based authentication.


Spoofing random browser information to defend against fingerprinting Tor goes the way of trying to make everyone look the same to defend against browser fingerprinting.

Wouldn't a simple addon that changes/adds as much information as possible randomly in short time intervals also do the trick? Are there downsides to this?

I am thinking about spoofing random fonts, addons (or addon version numbers), user agents (there is already an addon doing this).

Are there projects trying to do this? What are the downsides to this approach?

EDIT:
Comparing this approach to the approach which TOR uses (everybody looks the same)
On request I'll add what in my opinion this approach does better. You can't personalize your browser when using the approach "I want to look like anyone else". When just adding very much random plugin/fonts (whatever is possible information), which changes from time to time you can also personalize your browser. Sure, your personalized addons etc. won't change as quickly as the other random stuff, but now the server would have to check for every fingerprint, if there are any other fingerprints, where any of the information he uses to generate the fingerprint coincide with the new one. This sounds like a hell lot of work for me with a positive probability of getting false positives (associating two fingerprints with each other that aren't from the same user).

This approach is already used to some extinct as I see it. When wanting to be private, you will try to change your IP adress for example so it can't be tracked to you. Also changing the user agent is done (and there are already addons doing it in specific time intervals and randomly).

But why can't we pursue this approach: lets say we pic the 50 most popular addons/fonts, and always spoof having a random number of them installed in some random version

This isn't just limited to addons/fonts (I only read that information about these are often used for fingerprinting), but one could extend this approach to any information the browser sends. You'd have to send some real information (like window size) to have the site work properly. But then the fingerprinting algorithms can only rely on this minimum of real information you have to send (and not like panopticlick does it just on everything it gets).

To specify the question now:
Is this technically achievable? (Can you spoof browser information this good) And what are the informations you can't spoof because either it isn't possible to spoof them or because you need to send them for most sites to work properly. And are these informations already enough to be identified? Do modern fingerprinting algorithms already only depend on these "must-be-true" informations or do they (like panopticlick) use everything they can get their hands on

It is not easy to determine if some seemingly random changes are really random or if there is some underlying pattern/bias which might be used to track an individual user. On the other hand it is easy to implement and verify that the fingerprint is the same for all users and can thus not be used for tracking. Thus it is probably more safe to hide the identity of an individual user by making all users look the same.

Apart from that several web applications include the browsers fingerprint into the session cookie to detect session hijacking done from another browser. When the fingerprint randomly changes the session cookie will be invalidated a lot which can cause lots of inconvenience for the user, like the need to re-login all the time or loosing the articles inside a shopping cart etc.

EDIT: based on the recently extended question it looks like that the OP does not like the approach by TOR since it restricts the possibility to personalize the browser, add the extensions one likes etc. This is true but I would argue that the OP is not really aware how tracking and fingerprinting can be done and is done.

Yes, the simple fingerprinting just looks at the request and extracts information like User-Agent etc which could be easily changed. But this kind of fingerprinting gives only a rough idea of the user anyway and cannot be used alone to track specific users. More interesting tracking can be done with behavioral analysis, that is check for installed extensions, check in which social networks the user is logged in and much more. I really recommend to read Technical analysis of client identification mechanisms which covers a lot of different ways to track the user but is not even complete.

Thus, the idea of Tor to look the same is not restricted to make only the request look the same, but also to behave the same. With any extension you add and with any site you log in or simply visit you will change the behavior of the browser and thus look different from others. Randomization of simple features will not help because somebody who is  really interested in tracking you knows which features can easily be faked and disregards these. Behavior instead can not be easily be faked.


Is HTTP POST any more secure than HTTP GET for AJAX? All considerations of HTTPS/SSL, etc aside, if my user fills out a form and I send it by AJAX, it seems to me that POST & GET are equally interceptible, although GET is a teensy bit more transparent.

Is there any sound  technical reason to prefer POST?

You should use POST for any state-changing action. If you save the content of the form, or use the form to send an e-mail, you should use a POST.

There are several reasons why this is more secure:

CSRF is easier with GET requests than with POST requests. With GET requests you can simply send someone a link. With a POST request an attacker needs to have a crafted HTML page. When your framework has CSRF protection, this is typically only active on POST requets.
The browser policy is different for POST requests. For example, you get a confirm dialog if you try to reload the page. One example of where this applies to security is same-site cookies. With the "lax" setting, POST requests are blocked cross-origin and GET requests are not.

See also this answer.


Authentication via HTTP on VPN There is an authentication server (OAuth2) that is only accessible from private network.
A customer wants me to implement an app where users use VPN to authenticate themselves on such a server via HTTP (specifically not HTTPS)
I am not a security expert, but have a bad feeling about this. Is it safe? If not, what are the dangers of this approach?

Note: The app will be running on Android devices

If you consider that the network between the VPN's endpoint and the OAuth2 server is safe (because request are reencrypted, or it's a "trusted network"), then an HTTPS tunnel or a VPN tunnel offers the same level of security (encryption and authentication).

However, as stated in section 3.1.2.1 of the OAuth2 RFC:

  The redirection endpoint SHOULD require the use of TLS as described
  in Section 1.6 when the requested response type is "code" or "token",
  or when the redirection request will result in the transmission of
  sensitive credentials over an open network.

So it's highly recommended to have the OAuth2 server protected with TLS. If it's not, some credentials could be intercepted on the local network of the company in case of misconfiguration of some network equipment.

Also not that OAuth2 expect to have TLS everywhere, so some things can actually not work. For instance, some libraries could refuse to use some endpoints of /.well-known/openid-configuration if it's not HTTPS.

So: it's highly recommended to enable HTTPS on your OAuth2 server, but in your case it is not mandatory.


How can scammers inject pop-ups onto target computers? My grandfather recently fell for a telephone scam. I won't go into details into how the scam worked; it's sufficient to say that he sent them over $2000 worth of iTunes gift card codes.

The scammers walked him through installing "TeamViewer" then "helping" him with his computer (a Mac mini). "TeamViewer" is in quotes because I don't know for sure what they actually got him to install. It could have been a legitimate copy of TeamViewer, or it could have been a version of TeamViewer laced with malware. Since I don't know if his computer has been infected with anything, I'm going to have him mail the Mac mini to me. I intend to nuke it from orbit; it's the only way to be sure. I'll set him up with a non-admin account and manage it remotely.

Here's where the story takes an odd turn. The scammers called him today and requested that he turn on TeamViewer so that they could continue to "help" him. My grandfather said no, and the scammer belligerently said that he would block/disconnect his computer. I'm unsure of the details (since I couldn't see the computer), but my grandfather said that big messages appeared on his computer saying that his computer had a virus and that he needed to call a number. When he called that number, it was the scammer (no surprise). The warnings came repeatedly over the next few hours.

Here's my question: How were the scammers able to remotely trigger warning messages on his computer? If they had access, why did they need my grandfather to enable TeamViewer? If you still had access, it would be much more productive to just access it at 3am when he's asleep. If they didn't have access, how could they push the ads?

I will mostly likely receive the computer in the mail within 48 hours. Once I have it I will have a small window in which to examine it before I need to initiate the nuke. Are there any tests that I can run to check for malware?

To bad that your grandfather got scammed by those bastards, anyway scam is known as "Teamviewer scam", and since stammers had an access to the computer, probably they installed trojan for later deception which will bring them more money.

Second scenario according to BleepingComputer is:

  In some cases, parts of the TeamViewer app has even been embedded in
  malware directly, as to simplify the process of stealing data via a
  legitimate communications channel, disguising the data theft
  operations under TeamViewer traffic.

After all in case like your grandfather's it is good to do next steps:

1. Call Your Financial Institution and Tell Them What Happened

Chances are, if you bank with a larger well-known bank, they will already have experience with this type of scam and will tell you exactly what they can do in terms of putting a security alert on your account, dealing with fraudulent charges, etc.

DO NOT WAIT TO CALL YOUR BANK, tell them as soon as possible. If you wait too long then they might not be able to help you with the bogus charges.

They will likely put a fraud alert on your accounts and issue you a new card. If they don't offer to do this, INSIST on it.

2. Isolate and Quarantine Your Computer

Unplug the affected computer's network cord and turn off its wireless connection.

If you installed the remote admin tool as they directed, then they could be rooting around on your computer accessing your personal files, even after the phone call is over. They could also install keylogging malware to record your passwords as you access your bank and other accounts.

Once you've disconnected the computer from the network, read our article: I've been Hacked, Now What?  for information on how to backup your data, wipe its disks, and reload your computer. If you're not comfortable doing this on your own, consider taking your computer to a reputable local computer repair technician.

3. Monitor ALL of Your Accounts

You may want to consider signing up with a credit monitoring / identity theft protection service so that you can be alerted if and when scammers try to use your personal or financial information again.

4. Alert and Educate Your Friends and Family About This Scam

Even though this scam is affecting millions of people, there are surprisingly a lot of people who haven't heard about it and are still falling victim to it. Spread the word and share this and related articles with your friends and family. Educating people is the key to stopping this type of scam.

5. Change Your Passwords

After you ensure that your system is free of malware and keylogging software, change all your important passwords.

Make sure to choose strong passwords when creating new ones.

Source


What are the implications of an overly-restrictive password policy? I came across an interesting password policy online recently:

"Please be sure to enter a password that meets the following criteria:

must be 8 characters long
must not be based on dictionary words
must be different from previous 6 passwords
must contain at least 1 uppercase character (A-Z)
must contain at least 1 lowercase character (a-z)
must contain a leading letter (a-z or A-Z)
must contain at least 1 number (0-9)
may contain up to 2 special characters ($ or # only)
may not have repeating characters
must be different from user ID"

It seems to me that this narrows down the number of possible passwords so dramatically that it would take appropriately configured hackware all of two minutes to figure out someone's password. Is that approximately accurate?

You're right, it is a really interesting password policy.  Some of those rules are poorly defined.  If I apply a loose definition, I think it doesn't narrow the number of possible passwords to the point of making them easy to guess, but there are problems with this list:

Best protection of password is the length.  If it really must be exactly 8 characters, that is really bad.  I assume they mean 8 characters or longer. 8 characters isn't enough anymore in my opinion (even though this is recommended as a minimum everywhere).  Increase to 10 or 12.
repeating characters?  I assume they mean right next to one another  Who cares?  This doesn't do much to improve the guessability of a password.
Why only two special characters?  Why limit it to # or &??  This makes no sense.
Leading Letter?  Again, WHY?
No dictionary passwords is something I agree with, but how are they verifying it?  Do they have a database of dictionary words?

total possible combinations:
(26 + 26 + 10 +2) ^ 8 = 281,474,976,710,656
exclude combinations without numbers:
(26 + 26 +2) ^ 8 = 72,301,961,339,136
exclude combinations without leading letter:
(10 + 2) + (26 + 26 + 10 + 2) ^ 7 = 4,398,046,511,104
exclude combinations with repeating characters:
total possible - (64! / 56!) =  103,011,989,072,896

exclude dictionary words (words with 8 letters) round up to 10,000

final answer of how many passwords allowed:  101,762,979,777,508
So about 102 Trillion


Best Practices for Storing Digital Certificate I'm building an application where certain sensitive files need to be digitally signed before being stored in the file system using ASN.1 encoding, so they can be verified against a digital certificate (the one corresponding to the private key used for signing) at a later point in time when they're accessed. I'm using the Bouncy Castle library for Java.

There's a disagreement between members of my team regarding the best place for storing the digital certificate, and I'd like to know what's the best practice:

Storing the file contents, the signature and the certificate packaged together in a CMSSignedData object. In  this way, the verification procedure only needs to receive the CMSSignedData object, as all data needed for performing the verification is present in a single object.
Storing only the signature and the file contents in a CMSSignedData, and storing the certificate elsewhere. Using this approach, some extra work is needed for
managing the certificate and relating each signed file to the certificate needed for performing the verification.

I'm worried about the first approach, I believe someone could package and save the file contents, a certificate different from my own and a signature generated with the private key corresponding to that certificate - and the verification would succeed, because the verification procedure didn't receive the "original" certificate but a fake one.

What do you recommend? Do you see any shortcomings or potential problems in either one of the alternatives mentioned above? what's the best practice, or should I use an entirely different approach?

The first approach is better. Your concerns are misplaced. In the example you give, the verification should succeed. The data was indeed signed by the certificate it claims to have been signed by.

If I sign some document, then it's very important that it only appear to have my signature if it hasn't been tampered with. But if you can tamper with it but then have to put your signature on it, that's fine. You did sign its contents. I didn't, but it doesn't appear to have my signature. So that's fine.

You still must decide what that signature means of course after you decide it's basically valid. But that should be considered a separate step.

The design should be based on the fundamental security principle that an untrusted attacker cannot obtain the private key corresponding to the public key authorized by any certificate the system would accept as valid. Generally, it will be based on the common name in the certificate and the identity of the authority who signed it.

You can safely store the data, certificate, and signature together. This will allow you to validate the data and signature. The important thing is that you properly decide what that validation means by looking at the certificate.


Pattern to allow multiple persons to decrypt a document, without sharing the encryption key? Current setup

We have a service that allows users to upload documents through a website and stores the uploaded documents encrypted on disk.

The documents on disk are encrypted with a per-user key, which is randomly generated upon account creation. This document key is stored in a database field which is encrypted with the user's password as the key.
When the user (owner) want to download a document, they need to provide their password, which is used to decrypt the document key which is in turn used to decrypt the document.

We have chosen this pattern to negate the need to re-encrypt all encrypted documents when the user chooses to change their password: we only need to re-encrypt the document key.

This setup work fine (and we think it is a secure pattern1).

Required changes

Unfortunately, we have two new requirements to implement.

By law, we are required to be able to decrypt any documents we have on disk, upon request by the government;
Someone has decided that the owner of a document should be able to share the uploaded document with other users.

I don't know how to implement those requirements while keeping the documents stored with per-user encryption.

So, my question is:

Is there a known pattern that allows for encrypting documents so that they can be decrypted by one or more parties, where the parties in question are to be determined upon document encryption?

Update:

Some background information on the law mentioned above:
In fact, the law does not state that we are required to build in a back door. The law makes it a criminal offence to not hand over the key to any encrypted data you have2 if the police requests the key3. A result of this is that we who host the data need to have a back door, or face prosecution in case we cannot decrypt the data when requested. However, other than in some other countries, we are free to communicate the fact that we received an order to decrypt documents. These laws are unfortunately not uncommon.

Informing our customers and the public:
As I indicated in a comment before, I fully intend to pull my weight to makes sure this policy is clearly communicated to our customers. Privacy statements need be changed and TOS need to be updated.
Public awareness on the one hand and making sure 'bad laws cost money' on the other, are the best method I have available to protest against such laws.
However, at the same time I'm kinda sceptical about the impact of such statement. Most people simply don't care. At the same time, many people use their email and inbox to store and share documents. So from that perspective our service is (still) a huge improvement (and it is the reason some of our customers require their employees to use it).

1. If there is a glaring hole in this method, feel free to comment on it.
2. Lawyers have figured that 'data you have' is meant to include all data stored on physical devices you own (I'm not a lawyer, so this my lay-persons translation of what they concluded).
3. Yes, not some fancy security office, but police. There are some safeguards in when they can request password, but that doesn't change the implications of this law. The big question is what happens when you truly forgot the password to some data. The minister has indicated that it is the responsibility of the owner of such encrypted data to then delete it. But no such case has yet (as to my knowledge) been tried in court.

You need a per-document key, not a per-user key. Well, you also need per-user keys, but that is another matter.

Namely, each document D is encrypted with a key KD. That key is generated randomly the first time the document is imported in the system. Each document has its own key. The key for a document cannot be inferred from the key on any other document.

Each user U also has a key KU. Therefore, if you need document D to be accessible to users U, V and W, then you store EKD(D) (encryption of D with the document key), along with EKU(KD), EKV(KD) and EKW(KD) (encryption of key KD with the keys of user U, V and W). These "encrypted keys" have a small size (a few dozen bytes, regardless of the document size) so this scales up.

To make things more practical, you may need to use asymmetric encryption for user keys: encryption of D uses a convenient symmetric system (say, AES), but the "user keys" will be of type RSA (or another similar algorithm like ElGamal). That way, if user U wants to share the document D with user V, then he:

retrieves EKU(KD) from the server;
uses his own private key to decrypt that and recover KD;
encrypts KD with V's public key, yielding EKV(KD).

The beauty of this scheme is that V needs not be present for this procedure, since only V's public key is used.

At that point, what you really have is OpenPGP, a format meant primarily for secure emails. Emails have this "sharing property" (an email may be sent to several recipient) and are asynchronous (when you send the email, the recipient is not necessarily available right away). You would be well advised to reuse OpenPGP, a format that has been reviewed by many cryptographers, and for which implementations already exist.

When you have a sharing mechanism, you can simply put yourself as implicit recipient for every document, and you can read everything. Regardless of law requirements, be sure to notify users through the "usage conditions" that you can technically read everything; otherwise they may sue you for lack of warning.


How hardware firewall knows if its an inbound or outbound request? Being a hardware firewall, it can only see the TCP/UDP packets, how can they know that a packet coming inside is inbound or response to an outbound request?

Since there seems to be some confusion about the terms inbound, outbound, stateful and stateless, allow me to explain how they all relate to the concept of firewalls.

What is an inbound packet?

An inbound packet is a packet that enters a network. For example, if 198.51.100.23 would like to communicate with an internal web server 10.100.22.161, the request will be considered an inbound packet.

What is an outbound packet?

An outbound packet is a packet that leaves a network. If we take our previous example, the response from the internal web server 10.100.22.161 to the client somewhere on the internet at 198.51.100.23 will leave our internal network, and is therefore an outbound packet.

What is a stateless firewall?

A stateless firewall is a firewall that looks at each inspected packet in isolation - at least on the OSI layer it is designed to inspect.
For example, a simple firewall rule could be "Allow every incoming packet to the subnet 10.100.22.0/24 to port 443". The firewall does not know what the content of these packets is, nor does it care what packets came before.
All it does it look at its rules, matches them to the packet, and then executes whichever action is attached to the rules.

What is a stateful firewall?

A stateful firewall is a firewall that has some internal state related to what has happened before. For example, you might want your server to be able to communicate with clients, but only if they send a request first.
In order to do that, the firewall has an internal state of how the network traffic around it is like. It knows which clients have opened connections to which servers, and how long ago these connections are.
A simple stateful firewall rule could be "Allow every outbound packet from the network 10.100.22.0/24 on port 443, but only to clients who have an active TCP connection already".


How do I use crlDistributionPoints with keytool? I'm using the Java keytool command to generate keystores and openssl to revoke certificate and generate CRL.
However I need to configure crlDistributionPoints extension as described in the RFC 5280.

So is there a way to configure Distribution Points with keytool ?

Guessing here:
Use raw OID 2.5.29.31 with the generic -ext parameter.

But like Crypt32 said: This is terrible to manage.


How could malicious code changes in a GitHub pull request be masked by an attacker? When viewing a pull request on GitHub (or the equivalent on any other platform), the web interface displays a diff of the changes for you to review.

Reviewing the diff is obviously vulnerable to human error, as malicious changes can be snuck in (see mortenson/pr-sneaking).

Are there any obfuscation techniques that could not be reasonably spotted by a human performing thorough code review in the GitHub web interface?

One example is a homoglyph attack, that could potentially make a series of characters appear to a human as one value while actually being another.

There could also be a vulnerability/bug in the diff engine or output display that could be exploited to hide or mask malicious code in a pull request.

To clarify I am not asking about a human's ability to accurately review code changes - I am asking about potential spoofing/masking vulnerabilities that could be exploited by an attacker to deceive a human into accepting a seemingly legitimate pull request.

Bugs in the process of diff generation are unlikely.  Pretty much every web interface for a VCS system actually calls out to the VCS tool itself to generate the diffs.  Pretty much, any bug that might be there is pretty likely to be found and fixed quickly (it's generating user facing data, so any bugs there are high visibility).

Given that, your options amount to:

Homoglyph attacks, which you've already mentioned.  I don't see these as being very likely, as they are dependent on the font used for rendering, and they would have to be in data literals in most programming languages to not cause syntax errors, which in turn pretty severely limits what types of bug you can introduce.
Modification of binary files in the repo.  When dealing with binary data, most VCS systems only tell you the file changed, not how it changed, so there are no changes to review in the PR short of downloading and using the modified file.  This is one of the two reasons that sane people don't use version control for binary data, the other being that it's really bad at handling it efficiently.  Because not many people do this, it's not a likely attack vector.
Simple steganography.  This essentially relies on the reviewer not paying attention or not understanding the code they're reviewing.  The two obvious approaches are including a small change that introduces the bug in the middle of a couple of sections with lots of changes, or taking advantage of the fact that changes are shown per-line.


Securing IoT application I'm designing an IoT product, I'm searching solutions to secure the system.
The system's protocol is MQTT, while it's very helpful, it contains vulnerabilities.
I've read enough to come with this proposed system:

Using TLS: It's important, but it depends on support.
Apply a client-id prefix rule: The server wont accept any client-id other than ones meets a certain prefix, e.g. device-.
Authorization: Creating ACL (Access Control List) to allow each device to only subscribe to topics prefixed with its device-id rx/device00001/# and only publish to topics with the same property tx/device00001/.*
Limit the accepted messages lengths.*
Use authentication that depends on MCU's MAC address and a device-name:
Use device-id as client-id, and both device-id and MAC as password. Where MAC and device-id are securely shared to the server at flashing the firmware process.
Use application payload encryption.

Comments:

* Server terminates the client otherwise.
If TLS isn't used, an encrypted password is needed to secure-out the CONNECT packet sent to the server; because credentials are sent in plaintext.
Beside that: the password should be a function of UNIX time, to limit replay attacks. The time is used at server-side to checkout the freshness of the request.
If all security layers are used, Is there a need for application payload encryption?

Can you tell whether this system is secured or it contains threats?

I haven't worked with MQTT myself but did some research and looks like TrendMicro have an article on that:
https://www.trendmicro.com/vinfo/es/security/news/internet-of-things/mqtt-and-coap-security-and-privacy-issues-in-iot-and-iiot-communication-protocols
Some other Scanner tools are: Nessus and Tenable
you may give it a try on their trial version before you pay for any certificate.
hope it helps to some extend.