Is it known to what message size are standard hash functions injective?

(edit) This assumes "ideal" hash function design (a one-way function with no internal structure).  Actual implementations approximate this, and may have flaws which make them more predictable than they should be.

According to Wikipedia (summary bar on the RHS), "No actual collisions have yet been produced" for SHA-1.  The best we've done is find algorithms that "should" find collisions eventually.  SHA-1 has predictable collisions (SHAttered), but these collisions are definitely not the shortest, because they involve a prefix longer than the hash itself.

Since the point of a hash function is that any change (even a single bit) should change the whole result in a basically pseudorandom way, you're essentially looking at the birthday problem.

The table on this Wikipedia page lists the tradeoff between how many inputs you have and how worried you should be about a collision.  This other table here lists the "security" of each hash (in bits).

An example calculation: for SHA-512, with 256 bits of security, you have to be looking at 10^32 before you start to get problems.  log2(10^32) is about 106 bits, which means you should start worrying about collisions after about 13 bytes.  However, if you're picking them randomly, you might have other issues at that point, like your electricity bill and the death of the Sun.


How to determine risk ratings for third party mobile apps

In my department, I am involved in mobile device security, and have looked into a product that does just what you're looking for.

The product that I am familiar with is FireEye Mobile Threat Prevention.
https://www.fireeye.com/products/mobile-threat-protection-mobile-security-products.html

I have experienced some of the capabilities of this threat prevention system. It has the capability to scan apps installed on your MDM managed devices and will give the apps a "FireEye Threat Score."

This score is the result of analyzing how the application works on the mobile device, how secure the mobile device encryption, etc. It really does a good job of describing what vulnerabilities are present on any given app in your environment.

This is not only applicable for apps that have been scanned and indexed, it will scan new apps that might be specific to your organization and give you a threat rating.

We tested this product on an app that we were considering implementing, and the report gave us a 5 page report on the following information about the app:

Application Code (Detailed information about weaknesses were present in the application code)
System (Information about how the app interacts with the phone OS)
Phone (Information related to what phone functions the app needs to access)
Location (Info about what location services the app uses)
Settings (Settings on the phone that the app can change)
Internet (internet settings or calls the app makes)
Personal data (personal data that the app might contain)
File System (Changes to the phone file system that this app makes)


Professional certifications for IT Security

None.
Generally speaking, certifications in the security field, much like most other tech areas, are required only for entry-level positions (when you have no experience to speak of), senior positions (when you need the long signature), and government jobs (when you need to answer an RFP to work there).
By themselves, none of these are a replacement for good ol' experience and knowledge.

That said, these are the ones that get more "respect" (that I am familiar with):

CISSP
CISM
GIAC
CEH for a juniorish pentester

Also OWASP is supposedly coming out with their own cert soon, that would probably be respectable enough....


Does Apple maintain the security of the built-in Ruby?

They do provide security fixes relating to Ruby - for example the fairly recent Security Update 2013-002 includes some Ruby stuff, as did 2013-001. They don't seem to have patched CVE-2013-4073 yet, but to be fair that vulnerability is only a couple of weeks old.

As you imply in your question, the non-careless developer will never try and run a production web app with built-in stack components, but will download and install a separate copy somewhere else and keep that patched and updated appropriately. For one thing, they're very likely to want something more modern than 1.8.7!


RSA key size in TLS ciphersuite with RSA key exchange

Yes, it does mean exactly that that.

The pre-master secret in this protocol is a random generated by the client. It is simply encrypted using the public key from the certificate at the client and decrypted by the server using the corresponding private key. The pre-master secret is then used to calculate the master secret and the session keys.

The Finished message send by the server then shows that the server was able to decrypt the pre-master secret and derive all the key material: the finished message contains a MAC over all the messages using one of the derived keys.

This is all explained rather well in section F.1.1.2.  RSA Key Exchange and Authentication:

  ...

  After verifying the server's certificate, the client encrypts a
  pre_master_secret with the server's public key.  By successfully
  decoding the pre_master_secret and producing a correct Finished
  message, the server demonstrates that it knows the private key
  corresponding to the server certificate.

  ...

The key size of the public and private key of the same key pair is always identical. For RSA it is identical to the minimum number of bits required to encode the modulus as unsigned value.

Note that there is just one RSA encryption and one decryption operation that is used for exchanging keys and entity authentication; these are not separate RSA operations. The authentication part also requires the MAC, otherwise the client doesn't know that the server indeed decrypted the pre-master secret correctly. The protocol might have also have gone for implicit authentication when receiving the first message and verifying the MAC of that, but fortunately it didn't.


What steps should I take before using my credit card to buy something online?

Your first enemy when purchasing online is your own computer: a simple malicious plugin you may have installed within your browser may compromise your privacy dramatically (ZombieBrowserPack is a plugin developed originally as a POC and which you can install on Internet Explorer, Firefox and Google Chrome but can be manipulated remotely to steal authentication credentials, and even bypass two-factor authentication mechanisms such as the ones implemented by Yahoo and Google. It can also hijack your Facebook account, or get your bank account credentials if you perform an online purchase. You can imagine such a plugin purposed to fulfill this or that feature (shim) and doing something nefarious behind in the background.) So you need to scan regularily your computer against the presence of spyware and other types of malware by using firewalls, antiviruses and keep your connections encrypted.

Also, you better need to type the URL of the website you want to purchase on yourself instead of searching for it and clicking on it in a forum page, in an email sent to you (even from a trusted person as email addresses can be spoofed or even hacked using a simple but effective technique such as password guessing) because an attacker can craft a malicious link that will lure you to a website that looks like the one you were used to purchase on but actually is not. Note that a secure website you may purchase on must use secure connections (https) looking something like this:

Avoid using your laptop to purchase something online whereas you're in a public place where nefarious people may be interested in the codes you type to valid your transaction. Same advice is valid in case your purchase with your phone. Better to be patient to do the transactions once you're at home.

Be always careful: attackers are used to send emails pretending to be from your bank or any service you may use and provide you crafted links to click on and pay for something. Read the emails carefully and use common sense to see if you're not going to be trapped. Do not forget to save records of all your transactions (print them for example) just in case ...


Yes, someone with access to your key can logon anywhere the corresponding public key is deployed, gaining access to your data and with the potential to do further mischief ("stealing my identity" is a bit vague).

Carrying the key on a USB stick should mean the key is less exposed than sending it over the internet.

If you don't have a passphrase on the key, then you might consider adding one before exporting it (gpg --edit-key $KEY / passwd) or encrypting the exported file  gpg -e --symmetric $yourExportedIdFile).

If the private key was compromised then you'd need to remove/revoke the public keys from all the places they've been deployed.


Should I continue using this (potentially dangerous) website?

These does NOT tell the site is safe:

Kaspersky's green tick. It merely tells the site hasn't marked as a known harmful site.
HTTPS protocol, even with a trusted certificate, only tells your connection to the site is encrypted. This only means that the connection between your browser and the server is secured from 3rd parties. It has nothing to do with the content:

TLS protected sites can have vulnerabilities that can be used for modifying the contents. The site mentioned in your question is actually a good example of this.
Bad guys can buy or create free certificates for their web sites, too.

General look of the website. Most of the actually bad things happens when you don't notice. The longer you can hide, the more information you can steal.

A flickering website does NOT tell the site is malicious. It might look scary, but it's not a direct sign of anything else happening in the background. You'd have to look at the source code. This page had obfuscated JavaScript, but it was easy to deobfuscate. Most of the code was simply for creating the contents and the effects. It tries to load more JavaScript from external sources, but as they are all http:// resources on a https:// page, the browser refuses to load them.

The /wp-content/uploads/ is a standard directory for uploaded content. The site allows its users to upload own content, so probably some of such feature or other vulnerability was used to upload an index.php to that directory. The administrators of the site should be informed of such activities.


OpenSSL is a both a software library and a program (the "toolkit") which offers direct access to various features of that library.

A software library is a collection of program subroutines which doesn't do anything on its own but which can be used by other programs. In case of OpenSSL, these are subroutines which implement various cryptographic algorithms and protocols.

That means if a programmer wants to create a program which communicates encrypted, they don't need to implement the SSL protocol from scratch (or even worse, invent an own encryption system). They can simply link their program to the OpenSSL library and use the implementations which it provides.

This has various advantages.

The programmer saves a lot of time because there is less program code to type.
The programmer doesn't need to understand how the cryptographic primitives work on a deeper level. Cryptography is a very complicated and highly specialized field which very few programmers really understand (which is why we have a separate stackexchange site for it). So the availability of libraries like OpenSSL allows far more programmers to write programs with strong encryption, which benefits you as an end-user.
The programmer can use an implementation which is already widely tested by many other users, so it will likely have very few bugs.

IPsec is a protocol which uses a lot of encryption algorithms which are already available in OpenSSL. So the developers of your IPsec implementation likely saw these advantages and decided to make use of it. But that also means that their IPsec implementation doesn't work without it. That's why you need to install OpenSSL in order to enable IPsec.

But there is also a disadvantage: When OpenSSL does have a bug, that bug can potentially affect every single program which uses OpenSSL. This can create quite a fuss, like with the hearthbleed vulnerability in 2014.

Now about the program tookit OpenSSL. OpenSSL also comes with a command-line based program named openssl which allows to execute various functions from the OpenSSL library directly. For example the command line openssl dgst -sha256 -hex file.txt invokes the OpenSSL library function to generate the SHA256 message digest of the file file.txt and outputs it as a hexadecimal string. This usage is usually too cumbersome for normal end users, but can be useful for security professionals and server admins.


Do any cloud storage system offer an append-only mode for buckets, directories, etc.?

I don't know of any system that already implements this, but it should be pretty straightforward to build it yourself on top of existing cloud providers.  You just need to implement the logic to perform the append, read, and moderator operations.  If you implement the logic yourself, the backing store could be any existing cloud storage system.

If you also want a way to audit the storage system and (partially) verify its correct operation, you could use various cryptographic techniques.  For instance, you could use timestamping and hash chaining methods to enforce the append-only requirement (while nothing can prevent violations of the append-only requirement, timestamping methods offer a way that clients can potentially detect any violations that may occur).  Roughly speaking, timestamping methods work as follows: each message includes a hash of the state of the bucket at the time the message was appended to the bucket, and clients remember the latest bucket-hash they've seen.  This lets clients efficiently verify that nothing was removed from the bucket compared to the last time they queried its bucket-hash.

P.S. I'm not sure what the last requirement relating to "unapproved messages/files" refers to.  I didn't see where you explained how approval works, so I don't know whether there are any ways to externally audit the storage provider's correct implementation of approval functionality.


What user information does Wikipedia retain when a page is viewed?

The 'simple English' version of the privacy policy page describes what information is logged on page view:
http://simple.wikipedia.org/wiki/Wikipedia:Privacy_policy#Private_logging

64.164.82.142 - - [21/Oct/2003:02:03:19 +0000]
"GET /wiki/draft_privacy_policy HTTP/1.1" 200 18084
"http://en.wikipedia.org/wiki/Wikimedia_projects:Village_pump"
"Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5"

This log is said to be sampled but they typically store IP, timestamp, referrer and browser. Some countries do not allow conservation of logs containing IP addresses for more than 6 months (like France). Wikipedia says that "These logs are used to produce the site statistics pages; the raw log data is not made public, and is normally discarded after about two weeks."

Log data may be examined by developers in the course of solving technical problems, in tracking down badly-behaved web spiders that overwhelm the site, or very rarely to correlate usernames and network addresses of edits in investigating abuse of the wiki.

Derived data from this log are not supposed to be released except in the following cases:

In response to a valid subpoena or other compulsory request from law enforcement
With permission of the affected user
To Jimbo Wales, his legal counsel, or his designee, when necessary for investigation of abuse complaints.
Where the information pertains to page views generated by a spider or bot and its dissemination is necessary to illustrate or resolve technical issues.
Where the user has been vandalising articles or persistently behaving in a disruptive way, data may be released to assist in the targeting of IP blocks, or to assist in the formulation of a complaint to relevant Internet Service Providers
Where it is reasonably necessary to protect the rights, property or safety of the Wikimedia Foundation, its users or the public.

So it is again pretty vague...

Note that Wikipedia does not store cookie (tos-dr) and does not host third-party trackers (conf. Ghostery)


Short integer hashes to mitigate timing attacks on passwords

Really you want to ensure that the comparison function takes the same length of time regardless of the success or failure of the comparison.  Functions such as strcmp() etc may shortcut this and return failure on the first byte that does not match.

Likewise with higher level languages with string objects, where == and != can be used, we are reliant on the compilers implementation.

So to ensure constant time, a good solution is to always perform a byte by byte comparison of all the bytes of the hashed value, and then return true/false based on that comparison.

for example:

int contstant_time_compare(char *a, char *b)
{
    int i = 0;
    int len = strlen(a);
    int diff = 0;
    for(i = i ; i < len ; i++)
    {
         diff |=  a[i] ^ b[i];
    }
    return (0 == diff);
}


Forgot BitLock password- can I use dictionary attack?

If you have a TPM enabled, it contains a part of your key that's really difficult to extract, if I'm not mistaken. You can only bruteforce the part of the key that's derived from your password, which is not enough to decrypt your data.

The TPM will not enable the decryption if it detects that the system it's booting has been tampered with. So, no bruteforce bot.

Without lots of money and efforts, I would say that you'll have to try manually. But take all of this with a grain of salt, as I've never used BitLocker or a TPM, and don't know much about them.


Using RSA for Web Application Authentication

Are there any blazing "Oh, don't do that!" security flaws in the setup summarized above?

The basic protocol you are proposing is: client identifies themselves, server checks the public key and verifies that they are a valid user, server encrypts a challenge using the public key, client decrypts to get the challenge back and returns it as proof of knowing the private key.

I don't see any blazing issues. It may be better to follow what SSH itself does for public key authentication as shown in RFC 4252, section 7. There, they have the client sign something with the private key that the server can then verify. Always good to stick with standards.

  What are a few standard packages used in Linux for generating challenges using an RSA public key?

If you have openssl, I'd do this openssl rand -base64 16 (or possibly 32 bytes).

Otherwise, you can use /dev/random (or possibly /dev/urandom if absolutely necessary). Something like this head -c 16 /dev/random | base64. See this for more details

  Does anyone know of a good package for decrypting messages using a public private RSA key implemented in JavaScript?

A number of these libraries support RSA. Not sure how good they are and how easy it will be to transform the SSH private key into something they can use.

This answer is a summary of our chat


I accidentally entered password for a website as a username for another website

That sucks. I can't think of any other possible solutions beyond the ones you listed:

1) Keep at the technical support to delete the account (fully delete from all databases). This is probably your cleanest option.

2) Go around changing your password everywhere. I recognize this is a pain, and impractical / impossible for websites that you don't remember having an account on.

The main reason for posting an answer is to highlight your unfortunate situation as a warning to everybody else:

USE A PASSWORD MANAGER!!!!!!!!!!!!!!

This situation would have been completely avoided had you been using a password manager for all your accounts.

Had you pasted a newly-created random password into the account name field, then you go "oops", generate a new random password, and start the account registration over again (or live with a username like huWb9EIaemGZqVsp3aYV).

Even if - for some reason - you don't like random per-account passwords and you revealed a password used by multiple accounts, your password manager is a list of all your accounts, giving you a nice list of which are using that password and need to be cleaned up.

Finally, let's address:

  I have accounts in websites A1,A2,A3,...etc with password X or derived from X in some pattern.

Your situation is a great example of why "a password derived from X in some patterns" is essentially equivalent to "a password X".

I wish people would stop trying to be clever with patterns, and just used properly random passwords. (sure, password managers have usability issues, but they are far less risky than memory-based tricks)


What security considerations should I take when planning do to Incident Response in my hybrid public cloud environment?

A lot of this comes down to partnership, identification of responsibilities and communication between you and the cloud Service Provider (CSP)

Preparation

Identify who is responsible for monitoring suspicious activity. Do you capture logs, monitor and review logs and alerts? Does the CSP?

Identification/Analysis

If you suspect an incident, do you know who to talk to at the CSP?
If the CSP suspects an incident, will they contact you? If so, is this standard or an escalation path? i.e. are you informed in a timely manner or too late?

Containment

Do you have the tools to do this? Do you know what resources you're sharing with others? As a hybrid cloud offering, do you have other facilities, environments you can rely on? How do you identify infection and propagation thereof?
Who do you inform? Do you have to tell the CSP before you contain the problem? Must they take action on your behalf?

Eradication

Do you have resource available to eradicate when also containing?
Can you confirm eradication? Can CSP confirm or vouch for same?

Recovery

Do you have backups, clean images? Do you need to re-synchronise with other environments? Do you have mechanisms to achieve this and verify the integrity of your systems, applications, data once complete?

Lessons learned

If this happens again, can you reduce all the workload above? Based on how the situation was managed, should you give more or less responsibility to the CSP? Can you improve communication and transparency of activities? Is it possible to change those issues you identify require change or must alternatives be identified?


Base64 encode diffences in BCrypt implemenations

There's no difference here. Niels' implementation just goes one step further to verify that the correct bits are set/unset, by using & as a bitmask:

10010111 >> 4 = 00001001 (OpenWall's outputs this value)
0x0F = 00001111
00001001 & 00001111 = 00001001 (Niels' implementation outputs this value)

11010111 >> 6 = 00000010 (OpenWall's outputs this value)
0x03 = 00000011
00000010 & 00000011 = 00000010 (Niels' implementation outputs this value)

Notice that 0x0F masks all but the four rightmost bits, whereas 0x03 masks all but the two rightmost bits. Then consider that the shifts leave 4 and 2 bits remaining respectively, on an 8-bit value.

As such, as long as $c2 is an 8-bit value, the bitmask is unnecessary and the two implementations are equal.


Looking for feedback on my REST-style API authentication design and two-factor authentication

The problem is that what you call verification code is actually a Two-Factor Token. Tokens are normally short (like 6-7 characters).

So you'll do:

HMAC_SHA256(SHA1(TOKEN) + '#' + request_data + '#' + utc_timestamp)

And token is too short.

I also don't understand what a verified session_id vs an unverified session_id looks like.

The biggest problem is that this authentication scheme seems unnecessarily complex. Complexity and security are mostly opposites.

The way we suggest our customers (www.authy.com) to do two-factor auth is:

User sends a POST request with their credentials.
Server validates credentials. If correct the server generates a 256 bit string and saves it on to the database as well as returns it back to the browser. We'll call this string "otp".
The user is petitioned his two-factor token.
In the POST request of step 3 there will be:

hidden_field otp -> which comes back from the server on step 2
   text-field   two-factor-token -> which the person gets from his mobile app
At this point on your server you verify the two-factor token and the otp. If correct you
create the session and reset the otp so it can't be used again.


So I'm probably looking for some kind of a challenge-response mechanism here

I'd guess so. Print up a few pages of text in the following format:

# Challenge Response    # Challenge Response
1 monkey    character   2 sinew     orange
3 bottle    helmet      4 glass     glove

You'll both have the same list. Whenever you authenticate it doesn't matter who goes first. Provide a challenge word and check the response. You might say, "3 - Bottle," and wait for your friend to look it up saying, "Helmet." Both of you cross the number off the list and never use it again.

They're authenticated by providing the correct word in response. Then they pick a number and do the same thing to guard against a case where your friend may have challenged an attacker, thus providing them with a number-challenge pairing and using it in replay.

The words can be random letters, the result of picking random lines from a very long wordlist, etc as long as they're randomly chosen.


Can BIOS firmware log keyboard input? If so, is there any way to detect and prevent it?

Since the BIOS is generally the first thing that runs in a computer, using a PCI/PCI-E USB controller, bluetooth, or on screen keyboard would only "protect" you if the attacker didn't consider these cases.

This is still a problem because you're depending on whether or not the attacker did attack something rather than whether or not they can attack something.

While you can still count the number of BIOS attacks that have ever been published with your hands, technologies like Intel TXT can allow administrators enforce and audit BIOS security.

Unfortunately, this doesn't protect end users from nefarious code distributed by Lenovo themselves (which they now have a track record of). Essentially the only way to identify and prevent some sort of BIOS based keylogging attack is to:

Dump and Examine the BIOS yourself.
Use hardware from a vendor you trust more.

Ethical Disclaimer: My job involves Intel TXT


Execute an uploaded php script on a vulnerable server if I know it's location?

Unless the server is severely misconfigured, it will never execute .jpg files as .php files. The last segment after a . is the relevant one when determining file extensions, which means that you are uploading files that the server will correctly treat as jpg files.

So being able to upload script.php.jpg by itself is not a vulnerability.

If you for example had an LFI vulnerability somewhere, you could include the uploaded file, and then it would execute (regardless of file extension). Or if you could upload server config files (eg .htaccess in apache), you could reconfigure the server to execute .jpg files as .php files.

But those would be the vulnerabilities, not the ability to upload the .php.jpg file. It would be possible to check the mimetype on upload as defense-in-depth. But that can be bypassed, so I wouldn't consider not having such a check a vulnerability (even though checking is recommended).


When a sysadmin leaves what extra precautions need to be taken?

An admin should never have "super user credentials" that cannot be removed by simply removing his user account or move the user account to a group that lacks the permission.

An example: The admin logs in to a Linux system with his own account and uses sudo somecommand to do things that requires root permission. You don't allow this admin user to actually log in as root (and thus knowing a single root password that would have to be changed). There IS NO ROOT ACCOUNT to login to.

I think this principle can be applied to other access credentials as well.

Of course this only works if everyone actually follows the policy before they quit their job or get fired (or are moved to another part of the company). It does not protect against an admin who willingly breaks the policy and creates a back door for himself.


The article you are referring to is talking about SMS as the second factor. A better practice is to use an authenticator app (like google authenticator) as the second factor. This gives you a code that is only valid in a small window. Anyway if they have access to your phone this want help you either.

The problem with SMS as a second verification step is that it has several risks. NIST no longer advices to use sms-based 2 factor authentication (https://pages.nist.gov/800-63-3/sp800-63b.html section 5.1.3.2. Out-of-Band Verifiers)

So where possible use 2FA but with an authenticator APP.


How can I safely back-up files from an infected computer?

"How can they know that one of their files isn't infected"?  You can't.  Well you can if you get down into the bits of the file, but that's pretty tedious and expensive.

If you have an idea of the date the device got infected, files not altered before that date stand a higher chance of not being infected.  That's not a guarantee, because changing a file's date isn't hard.  So even that's not foolproof.

Really the only halfway decent option is to scan the file, copy it to an external drive, then scan it again and copy it back.  Odds are that it's a generic and not a targeted infection.  By waiting a couple days, to give AV vendors time to update their virus definitions, you stand a better chance of removing the infection when you move and scan the files.  That's not 100%, though - unless you know the infection and that the AV in question resolves the infection, you could set yourself up for a reinfection.

The only safe alternative is to wipe everything and have the user buy an external hard drive.  Then they should use it regularly to back their files up.


Automatic detection of credential leaking and secret servers

This will not be a full answer, since a full answer is not possible:  A credential can be anything that you may want to make into a credential.  But assuming that the credentials are sensible we can argue about two things:

The first paper you mention simply makes a scheme in which an unauthorized access provokes an alarm (wrong codeword in the paper) which disables the key.  In implementation terms this isn't much different from: "after three unsuccessful logins the password is blocked".

The novelty of the paper is only that they make a full keyscheme (with formal analysis of the scheme).
The second paper talks about something completely different.  It is just an enumeration of how systems that publish user data to the web (e.g. github or bitbucket, but it could well be facebook) try to find that inside the published data there are strings that look like credentials to somewhere else.  This is pretty similar to what scumblr can be configured to do.  Their list of techniques includes rather simple points:

keyword search (e.g. BEGIN RSA PRIVATE KEY)
pattern match (e.g. search for base64 encoded strings)
heuristics (pattern match but using context)
source search (pattern match but using guesses based on the type of source code it is searching)

These things work, I remember receiving an email from BitBucket when once upon a time I submitted my AWS API key to a repository.  But as for their implementation as a specific tool I believe they're just scripts that are invoked as git hooks.  Look at this image in the paper:

The "key detection module" is called between a user commit and the actual commit to the public repository.

Github and BitBucket certainly has a database of patterns that are likely to be credentials.  And also they certainly have a couple of heuristic algorithms.  Points 1 (keyword search) and 2 (pattern match) are trivial to implement with grep, points 3 (heuristics) and 4 (source search) require a good deal of pre-existing data which only places like Github and BitBucket would have.

Finally note that even the paper argues that the heuristics and source search produce both false negatives and false positives.  Therefore there is no magical solution here.

Had I needed something to check for users on my website publishing their credentials to somewhere by accident I'd try to use points 1 (keyword match) and 2 (pattern matching) and then simply build a heuristic algorithm that does not depend on so much on pre-existing data.  On way would be to try Kolmogorov complexity (see this old question about string complexity from more info).

The assumption is that complex credentials will have a lot of entropy by byte since they should be difficult to brute-force.  This is a bad assumption in some cases: for example base64 encoded strings have little complexity compared to their length.  We will need to catch base64 strings in the pattern match phase (phase 2).

Here is a trivial (it uses zlib to approximate Kolmogorov complexity, which isn't particularly close) heuristic algorithm using the assumption above:

#!/usr/bin/env python3

from io import BytesIO
import zipfile

strings = [ b'password password password password'
          , b'correct horse batter staple'
          , b'HdtfhhaissdogkanfhhwnaHDnbahdnSGENdkfQWee=='
          , b'hZjJIdkXndjaodk='
          , b'\x89\x12\x03\x561w\x10'
          ]
for s in strings:
    fp = BytesIO()
    zf = zipfile.ZipFile(fp, 'w', zipfile.ZIP_DEFLATED)
    zf.writestr('f', s)
    zf.close()
    print('%50s' % s, float(len(fp.getvalue())) / float(len(s)) )

And its output:

        b'password password password password' 3.257142857142857
                b'correct horse batter staple' 4.777777777777778
b'HdtfhhaissdogkanfhhwnaHDnbahdnSGENdkfQWee==' 3.3255813953488373
                           b'hZjJIdkXndjaodk=' 7.375
                        b'\x89\x12\x03V1w\x10' 15.571428571428571

As expected it works well to separate simple strings from strings that are sets of more-or-less random bytes.  Yet, it works badly on base64 strings and even on some passphrases.


Is it possible to hack a database inside of local network by external attacker?

If there was a standard, easily answerable way to make a local network "absolutely secure", most of the community here would not have jobs. It's not nearly that simple. Network security is incredibly complex. And the environment, the people using it, and the people attacking it are constantly changing, adapting, and evolving.

Can an attacker from global network hack a ... machine inside of local office network?

Of course. This happens all the time.

maybe there is another way...?

The answer to that is "how many paths could there be?" The more direct route is to infect the machine's administrator's PC with malware and use that to access the machine. That's just one "hop" to the target. But one could use whatever means necessary to create one's own "network" to reach the target. And this happens all the time, too.

turn the database on just when it's needed

This is a form of "air gapping" and this, in a crude way, implements a security principle that things should only be accessible when they are needed. But the costs and inconvenience tend to be very high for this approach, and it is still vulnerable once it turns on.
If you are looking for an approach to start designing security for this machine, there are multiple frameworks that you can use as a guide. At a high level, and broadly applicable, the NIST CSF provides practical, actionable factors to consider. But nothing will make it "absolutely secure". You only increase the chances for the machine to remain in a secure state.


Is session/cookie based authentication stateful or stateless?

Is it correct that session based authentication is the same as cookie-based authentication?

These phrases are not the same: "cookie based" reflects how session information gets transmitted while "session based" reflects that a session is used instead of having to login for every transaction again. "Session based" might be implemented with cookies and it typically is, but this is not an actual requirement. One could transmit the session for example in the URL too.

  Does session/cookie based authentication store user/session/... on server side?

Not necessarily. All information can be stored inside the (signed/encrypted) cookie so that only the client actually stores the information and the server can extract the information from the cookie. Or the cookie can just be a key to look up the information in the servers database in which there is no need to sign/encrypt it.

  Is it stateful or stateless?

Depends on the meaning/interpretation of these terms in a specific context. First, there is always a state involved when having a session, compared for example to the case where authentication credentials are send with each request. So from this perspective session based authentication is always stateful.

But in some contexts the question is if both server and client keep the state information. In this interpretation it would not be stateful if all the state information are contained in the session cookie, since the server only extracts the state from the cookie and might update the state by sending a new cookie, but does not actually store the state locally.

  Is the difference between cookie based and token based authentication exactly that the former is not signed, while the latter is?

They are not the same but similar. A session cookie is usually set initially by the server and then implicitly reflected by the client in each request by the client inside the Cookie HTTP header field. An authentication token is usually created some other way (for example when signing up for a service) and is explicitly added to the request by the client, usually inside the Authorization HTTP header field. Both session cookie and authentication token are opaque to the client in that it does not care (and often does not know) the inner structure.


Is there any good reason to choose IDS over IPS?

Passively listening to network traffic to detecting suspicious behavior is still important. There are only a few obvious attacks which you might detect and block immediately but there is lots of traffic which only looks a bit suspicious or even innocent. But, if you collect traffic information over some time and maybe from multiple places in your network, you might see a pattern in this innocent traffic which points to anomalies or attacks which try to be stealth (like APT).

Apart from that, the meaning of words like IDS, IPS or firewall is not clearly defined and they are mostly replaced today by even more blurry marketing speech like "next generation firewall" or "unified threat management". The classical IDS products like snort, bro and suricata still exist and are in active development, but they are mostly integrated in UTM or NGFW solutions or things with different marketing names.


How Do I find Out the Username And Password Of Wifi Windows 7?

Get something like Hiren's boot CD and burn it from ubuntu or windows
Boot into the environment to Reset the admin account or add a new administrator account using this hack directly from within Ubuntu.
Boot into Windows and Log in with your newly created or reset account
Download and run THIS software from Nirsoft as administrator under Windows 7.
You should now have the password.

Hope that helps


BLS signature java implementation needed (if possible, along with some example code)

The Boneh-Lynn-Shacham signature scheme works only in special elliptic curves that support efficient pairing computations. This is not something that you somehow add on top of an existing signature; it is a signature algorithm in its own right, that uses its own kind of public/private key pairs. If you want something that works with X.509, then you need a public key that can be encoded as part of an X.509 certificate. Currently, there is no defined format for a public key appropriate for BLS(*); X.509 is an open-ended standard so you could conceptually define your own format and make your own implementation, but:

This is an endeavour of considerable scope. It would require from you thorough knowledge of ASN.1 and DER encoding, elliptic curves, and pairings over elliptic curves (which is a plunge into rather hairy mathematics); and also strong skills at implementing cryptographic algorithms.
Since that would be your definition, there would be no interoperability with the implementation of anybody else, so your signatures would be verifiable only with your own software. At that point, why bother with X.509 at all ?

The advantage of BLS over a more common signature scheme, such as ECDSA, is that it produces shorter signatures. Shorter, not necessarily short. If you want n-bit security (traditionally, n = 128; current technological limit to the breakable is somewhere between 75 and 85), a BLS signature will need to have length at least 2n bits, while ECDSA requires 4n bits. Note that even with BLS, we are still talking about at least 200 bits or so, which is a lot for human-powered input. For instance, a Windows product key uses 25 characters taken in a 24-sign alphabet, which is sufficient to encode up to 114 bits, no more (because 2425 is approximately equal to 2114). If you want human users to type signature values, then even with BLS you are considering an effort similar to entering two product keys (four product keys with ECDSA). In most contexts this is probably too much to ask (indeed, if you could ask for more, then Microsoft would also do it and use longer product keys, precisely so that they could use cryptographic signatures like BLS...).

If you still want to delve into BLS, then start with the PBC library. It is written in C, but the conversion C-to-Java is the least of your worries -- understanding the usage context and the maths is a lot harder. I am not aware of any openly available Java implementation of pairings, but it is absolutely doable (I can guarantee that, because at one point I wrote a pure Java implementation of pairings). Depending on your existing knowledge in maths, crypto and development, obtaining a functional, reasonably secure implementation could take you several years of full-time work. Personally, I have already done that once, so I know all the maths and crypto, and I have done a lot of crypto implementation in Java, and it would still take me at least two or three weeks of full-time work to produce something that could be described as "decent".

Edit: actually a simple Google search with terms "BLS signature java" uncovers jPBC, which appears to be a Java port of PBC. All my points about the need to understand the maths, and the interoperability issues, still hold.

(*) It is possible to encode a BLS public key using the generic format for elliptic curve public keys, but that format does not include any field to notify decoders that the curve is appropriate for any specific kind of pairing. Even if the software receiving that key can recompute the embedding degree, there is no way to indicate the pairing type to use (Weil, Tate, any distortion map...).


Can you trust your computer devices to be safe to use if they have been in the hands of potential hackers?

What you are describing is called an Evil Maid attack.

The short answer is NO: you cannot trust them.

The long answer is MAYBE: depending on the hardware manufacturers of your devices you can verify the integrity of the data and the firmware of their components. However, I still not know any easy solution for all of them as a whole.

For the BIOS and internal HDDs/SSDs you can use a TPM with Anti Evil Maid, which lets you store a secret inside the TPM and only releases it if the BIOS and storage haven't been tampered with.

For the external storage you can always store checksums on other devices (or even on paper) and verify them later without mounting the drives.

When it comes to the firmware of USB devices, storage devices (internal or external) and mouse, there may be some vendors that allow downloading their firmware or dumping it easily from the device itself. However, in most cases it would have to be extracted from the memory chips and compare it to the previous one to verify its integrity. PS/2 mouses and keyboards present an interesting alternative from this point of view, but they are becoming rare history museum items nowadays.

Many home routers (and all of them should) allow downloading firmware binaries from their manufacturers' websites and flashing them again in recovery mode.

However, as most of the manufacturer's firmware is proprietary, one should ask the following question: can devices be trusted with their original firmware itself?


MVC - Dynamic Routing potential security problem?

Yes, this is a vulnerability. OWASP calls it Unsafe use of Reflection, and as they state:

  in larger applications where complexity grows exponentially it is not
  unreasonable that an attacker could find a constructor to leverage as
  part of an attack


Advantages of separating Web server from Database

Well the first obvious advantage is that if someone breaks the box that houses your application server, they are not guaranteed access to the same server that houses the database.  Also, by separating this functionality you make it easier on the IT (software devs, admins, etc) to minimize code change impact / policy updates on different aspects of the environment.  This does not in any way fix poor coding or weak security (SQL injection, default username/passwords). but it does facilitate a better security posture overall.


Is it safe to ignore DoS attacks on my router?

Looking up these IP addresses in Google give the following results:

31.13.91.117 => related to Facebook
88.221.82.74 => related to Akamai

Given the fact that Akamai is a content provider (CDN) which has reportedly been having Facebook as a customer, it seems that this might not be a real DOS attack, and that your router's protection is exaggerating. Is it possible that a lot of your employees/family members use Facebook, which causes a lot of (legitmate) Facebook responses to come in on your router? The router might see this as a DOS-attack, when it is in fact not. This is supported by the fact that the 'scans' come from source port 443, which is the TLS (HTTPS) port. You are connected via HTTPS to Facebook, and they reply to you.

The other IP addresses listed in your question seem a little bit more shifty, but again, this might be a legitimate site which is sending a lot of responses (lots of CSS, JS, etc.). However, the ones that list port 30372 and 18668 are very shifty. These may be part of a massive scan or just a coincidence. I wouldn't worry about them if they don't appear regularly.


Which is better for server-to-server-communication: IPSec or TLS?

There are two main usage modes for IPsec: AH and ESP. AH is only for authentication, so I suppose that you are talking about an ESP tunnel between the two servers. All IP packets get encrypted and authenticated, including some header details such as the source and target ports. There are several encryption and MAC algorithms which can be used with IPsec; AES (CBC mode, 128-bit key) and HMAC/SHA-1 (truncated to 96 bits) are fine, and are MUST-implement, so any conforming IPsec implementation should support them.

For this "tunnelling" part, IPsec does things correctly, and so does TLS (assuming TLS 1.1 or 1.2, for IV selection with block ciphers in CBC mode). In fact IPsec can be deemed to be "more correct" than TLS because it uses encrypt-then-MAC instead of MAC-then-encrypt (see this); however, properly implemented TLS 1.1 or 1.2 will be fine too. Practical differences will occur at other levels:

To encrypt and decrypt data, your two servers must first agree on a shared secret. This is what the handshake in TLS is about; the equivalent in IPsec would be IKE. You might want to rely on X.509 certificates; or maybe on a "shared key" manually configured in both servers. Both TLS and IPsec support both, but any specific implementation of either may make one option easier or more complex than the other.
IPsec acts at the OS level; application software needs not be aware of the presence of IPsec. This is great in some cases, not so great in others. On the one hand, it allows some legacy applications to be "secured" with IPsec even if this was not envisioned during application development; and the security management can be done without being constrained by what the application developers thought of (for instance, if using X.509 certificates, you can enforce revocation checks, whereas a TLS-powered application might use a library which does not support CRL). On the other hand, with IPsec, applications cannot do anything application-specific with security: a server may not, for instance, vary its security management depending on which other server is talking to it.
Though TLS is normally used applicatively, it is also possible to use it as building block for an OS-level VPN between the two servers. This basically means using TLS as if it was IPsec.
IPsec being OS-level, its operation implies fiddling with OS-level network configuration, whereas TLS can usually be kept at application level. In big organizations, Network people and application people tend to live in separate worlds (and, sadly, are often at war with each other). Keeping everything at the application layer may make the deployment and management easier, for organizational reasons.

Summary: it depends. Use IPsec if you want to apply it on uncooperative applications (e.g. an application which does not natively support any kind of protection for its connections to other servers). Use TLS if you want to abstract away OS-level configuration. If you still want to use TLS and yet do so at OS level, then use a TLS-powered VPN.


In theory, password strength checkers do not work. That's because the strength of a password does not depend upon the password value (which you give to the checker) but upon the password generation process (which you do not formalize often, let alone enter in the checker).

In practice, password strength checker use a set of rules which describe common password generation methods; they then tell you how long your password would resist if the attacker uses exactly the same rules. But the attacker does not use exactly the same rules. The attacker is after you; he knows you (if you are attacked only by people who do not know you, then you can consider yourself very lucky -- or very uninteresting). Therefore, the attacker will amend his password brute-force methods so as to target your psyche, your probable password generation methods.

Password strength checkers are good at telling you how robust your password is against incompetent attackers. This has some value, if only because there are so many incompetent wannabe hackers. But it would be a mistake to rely too much on such tools.


Why are websites obviously run for nefarious reasons not taken offline asap?

There are several reasons for this.

1.) It may be very hard to track down the owner of the server.

2.) The server may be hosted at an ISP in a country that speaks a very different language than the language of the people being targeted. Think about hosting a fake website for a very small mid-West US Bank at a Japanese or Korean ISP. Figuring out who to even contact may be a bit of a challenge then you have the language barrier (BTW: Google translate is great for this situation and most ISP's want to help you).

3.) Some countries don't care about this (The Russian Business Network has a lot of well known IP addresses hosting a world of bad stuff but no one can get the Russian government to do anything about this).

4.) Some governments either don't have the resources to do anything about this and don't want to get involved (possibly too busy with a war or other critical issues) and do the ISP's don't even bother.

5.) Some ISP's are very small and understaffed and possibly have a big list of other to-do items like taking care of paying customers so this just takes a while.

6.) ISP's that are on the edge of going out of business will take any money they can get. The bad guys are paying customers in many cases.

7.) Some organizations have bad security and when they get hacked they don't notice for months. This allows an attacker to setup a website, especially a virtual webserver, on an insecure webserver and run it for a long time.

etc...

In the long run it's not that some people don't spend effort to get these taken down generally people do but the sites pop up again very quickly and for some attacks a site being up for 24-hours is very effective and can potentially infect millions of computers.

Ultimately there are a lot of other reasons but these are the most common.

Hopefully this info helps.


are chrome extensions in the Chrome store generally safe?

Can I trust a chrome extension to not secretly do malicious activities in the background? If so, why should I be able to trust these extensions? Is the Chrome store curated by Google?

You cannot fully trust the chrome store.
For examples of malicious behavior see Uncovering Malicious Browser Extensions in Chrome Web Store from 09/2014, Adware vendors buy Chrome Extensions to send ad- and malware-filled updates from 01/2014 or Can you trust your browser extensions? Exploring an ad-injecting chrome extension from 10/2014.

The idea is often the same: gain some initial trust by being a well behaved extension and later turn bad.


Level 4 merchants becoming PCI Compliant

You have to report on PCI compliance if you are a level 4 merchant. You need to complete a self assessment (SAQ). So to become compliant you need to:

Complete the Self-Assessment Questionnaire according to the
instructions it contains.
Complete and obtain evidence of a passing vulnerability scan with a
PCI SSC Approved Scanning Vendor (ASV). Note scanning does not apply
to all merchants. It is required for SAQ A-EP, SAQ B-IP, SAQ C, SAQ
D-Merchant and SAQ D-Service Provider.
Complete the relevant Attestation of Compliance in its entirety
(located in the SAQ tool).
Submit the SAQ, evidence of a passing scan (if applicable), and the
Attestation of Compliance, along with any other requested
documentation, to your acquirer.


DNS communicating with a remote host on an unusual server port 53

Based on the setup described in the question and comments this kind of traffic is likely innocent. You seem to run a DNS server which recursively resolves the domains. In order to resolve a domain it would need to query multiple DNS servers, starting with the root servers. The DNS servers which are queried might be all around the world, depending on the domain which need to be resolved. And it might for example be a simple typo in the domain name which makes the DNS server visit strange locations which are usually not visited.

If you don't want to have this kind of traffic you might configure a fixed forwarding DNS which does all the resolving. Any DNS traffic which is not send to this forwarder can be considered suspicious then.


TLS (and SSL) used or uses SHA-1 in three ways.

1.0 and 1.1 used HMAC-SHA1 for data integrity in nearly all ciphersuites (a few old ones used HMAC-MD5 but they have mostly fallen by the wayside already). 1.2 adds some new ciphersuites that use HMAC-SHA2 (SHA-256 or SHA-384) and some new ciphersuites that use AEAD which combines integrity into the encryption (specifically AES or some others with GCM, AES with CCM, and ChaCha20-Poly13505; in practice only AES-GCM and ChaCha are common).

The HMAC construction blocks collision attacks like the new one for SHA1. Ciphersuites using HMAC-SHA1 remain as secure now as they were before, and as secure as HMAC-SHA2 -- which is, not entirely, because there already were and still are attacks unrelated to the hash. Specifically, all HMAC ciphersuites either use RC4, which is badly weakened and now prohibited from all vesions of TLS, or CBC-mode ciphers with MAC-then-encrypt, which have been subject to a series of padding-oracle attacks -- and in 1.0 also a known-IV attack (BEAST). The fix to these attacks is to use AEAD ciphersuites (with neither HMAC-SHA1 nor HMAC-SHA2), which requires 1.2.
"SHAttered" makes no difference. You should already have preferred 1.2 with AEAD not HMAC-SHA1 OR HMAC-SHA2, and you should still.
PRF and key derivation. 1.0 and 1.1 used a combination of double-HMAC-MD5 and double-HMAC-SHA1 for the PRF used in the handshake for key derivation and Finished; 1.2 uses double-HMAC-SHA2. As above HMAC protects against the collision attack, plus the key derivation and Finished data are substantially uncontrollable by an attacker anyway. No difference.
Certificates. TLS, including 1.2, usually (though not quite always) relies on certificates and their signatures, and collision attack can endanger certificate signatures in at least some cases. This was true for MD5 with the 'rogue' attack a decade ago, and resulted in fairly rapid retirement of MD5 certificates. The community has recognized for years that SHA1 certificates were similarly at risk: CAs have been forbidden to issue SHA1-signed certificates for at least 2 years, depending which authority you go by, and some (most?) browsers, some other clients and servers, and many tools (notably SSLLabs widely used tester) have been warning more or less noisily and intrusively about SHA1-signed certs for a least a year; now, as the shattered website notes, some (many?) will soon start rejecting these certs.

If you are still using SHA1-signed certificates; stop. This applies to all versions of TLS and also non-SSL/TLS uses of certificates such as email encryption and code signing.

So in conclusion, "SHAttered" does not provide any additional reason to use 1.2, but there was already good reason for 1.2. It does provide more reason to use SHA2 certificates -- everywhere, not just TLS. The only actual reason to switch to 1.2 because of "SHAttered" is because the publicity, noise, hype, fearmongering, and widespread incomprehension give you leverage to pry resources and approvals out of managers who don't understand the issue anyway.


Robust SSL pinning on IoT device with Let’s Encrypt

It looks like you want to accept any certificate issued by Let's Encrypt for your specific domain. This is done implicitly without any pinning if your only root CA on the device is Let's Encrypt (provided of course that you do the usual proper certificate validation). If you have multiple root CA on the system you might pin at the specific public key of the root CA you want to use.

Another option would be to not care about the CA at all but instead ping against the public key of the leaf certificate. Usually this public key stays the same if one is just renewing a certificate, i.e. one will submit a CSR with the same public key as in the previous certificate. In case the private key was compromised you might also have some more spare keys you could use to create a new certificate and have these setup for pinning on the device too.

I'm not sure what the current capabilities of the ESP8266 platform are currently regarding certificate validation. But as far as I remember there was a time when all it could do was to check for a specific leaf certificate. In this case the second option of pinning against the public key of the leaf certificate and reusing the same key with certificate updates should be easier to implement.


How to separate storing sensitive data and hash passwords?

Regarding Question 1:

In general case — yes, it does. You don't know the details of a potential future attack so your job is to make an actual exploitation of any vulnerability as hard as it possible.

As you know, information security mission is to provide three values: confidentiality, integrity, and availability. Let's assume that a hacker gained a full copy of your DB (which affects confidentiality). Being able to log in as a user, he can take over integrity (by modifying user's data and performing actions on their's behalf) and availability (e.g. by changing email which can be used to regain access.

Before switching to question 2. As far as I know, MongoDB also has access control on a collection level, so it could help to limit attack propagation. You can also consider encrypting sensitive entries in a DB so unauthorized read-only access will won't be as critical.

Regarding Question 2:
There is no a right way because security decisions need to be done based on many factors which can be derived from risk-analysis. You can store user creds in a different DB or create a separate auth server, or use 3rd party auth services (OAuth).

The main goal here is to keep a balance between the price of implementing, supporting those security controls and a potential loss you might have in case of a data breach. My intuition is to keep it simple and follow basic security recommendation (like password hashing and access segregation using MongoDB access control tools) combined with other security controls of the system (like strict user input validation) you can find, for example, in OWASP ASVS checklist.


Hostnames reveal interesting information, such as potential code sinks (e.g. ldap1.internal.companyname.com would be LDAPi versus db1.internal.companyname.com, which would be SQLi). These can be extracted with the host-extract.rb tool.

Parameters reveal the same type of information, and may even speak words about the type of query. For example, I often see ASC or DESC listed as parameter names (especially on sort buttons in web apps), which would indicate an ORDER BY or GROUP BY injection type. Sometimes the parameter names are sortby, groupby, or perhaps sortorder or simply "order" or "group". These are very telling.

Additionally, some are called "limit" or "offset" which indicates the LIMIT or OFFSET part of a SQL query. A web application assessor usually assumes he or she is injecting into the WHERE clause, but it really could be in these other places.

Some parameter names give other hints, such as whether they are an integer or string.

Often, SQLi exploitation tools, such as sqlmap, Marathon, and bsqlbf-v2 will allow you to configure the attack query more specifically, and yes, knowledge of the current parameter keys and values certainly helps when testing them, especially during blind SQLi testing!

File names (via a path disclosure) are even more obvious. They can be used to discern whether or not a popular open-source (or potentially closed-source if you read a lot of code!) package or component is installed on a web server. You can usually get down to the specific version. InspathX and WhatWeb utilize these techniques -- inspathx to identify path disclosure vulnerabilities and WhatWeb, well let's just say that WhatWeb can do a lot!

Since about half of the tools that I mentioned in this answer cite tools made by current members of the YGN Ethical Hacking Group, you should check out their Research area and Lab (accessible from their main webpage).

The authors of "Hacking Exposed Web Applications, 2nd Edition" (Note that the third edition is out, where additional up-to-date information is available) are referring mostly to custom directory/file brute-forcing lists, as well as Direct Object References (i.e. OWASP T10 Forced Browsing, OWASP T10 Failure to Restrict URL Access, OWASP Insecure Direct Object References, or WASC TC Predictable Resource Location).

In other words, if you see something like http://owaspbwa/external/ you could also check for the existence of http://owaspbwa/internal/ or similar.


How the inability to modify the title of javascript alert() function helps in anti-phishing

tl;dr: It (mostly) doesn't.

The real reason why you can't modify the title is that there is no title in the spec. An alert is meant to display a simple message, not to create a complex new window.

If there would be a title parameter, it would not have any impact on security if you were able to change it. An alert is a very weak element for phishing attacks, as it can only display a simple text message (you can't even insert clickable links, so you would need to tell a user to copy-paste a link - except that copying is disabled in some browsers). Apart from being very limited, there is no reason to believe that a user would have more trust in an alert box than in a website regarding phishing attacks.

The impression that it may have an effect on security may come from the fact that browsers decide to include the originating website in the title. So an attacker may for example host JavaScript on their server that displays an alert with the title "google.com says: [...]". But I don't see a real danger here. There is no possibility to enter data in an alert. And even if there were, a user who trusts the alert would likely trust a simple phishing site without an alert as well.

As an alert is part of the browser ui, not the website ui, customization of the look and feel of an alert may provide a danger of impersonating the browser, not another webpage. So an attacker may set the title to "Important security notice" and the message to a description to copy-paste a given URL to install a "security patch". As the alert seems to originate from the browser itself, a user may follow it. But even that seems rather far-fetched to me (and being able to edit the title of a message seems a minor point here; such a user may be just as easily fooled by a message displayed inside a website itself, which has a lot more possibilities to style a message and to receive data entered by a user).


How to add subject alternative name when converting PEM certificate to DER format?

No, of course not, this would change the certificate and invalidate the signature. You're asking the exact same thing as "I have a certificate for a domain I own, chedy.com, and I want to add google.com to the Subject Alt Names list, what is the openssl command for that?".

The difference between DER and PEM is just a base64 encoding.

You need to generate a new certificate with the SAN you want.


Where can I find a list of Indicators of Compromise (IOC) conditions?

Unsure of where you can get a list from, but the IOC Editor may have visibly similar options. Meaning, you can browse the options to see what is available, and how it works. I'd also have a look at IOC Finder to see what options are available on that as well.


Why can't I pretend to be someone already connected to WiFi?

I asume you are talking about WPA2-PSK here - the protocol commonly used for WiFi at home or at a coffeeshop.

During the four-way handshake, when the connection is set up, both the client and the access point prove to each other that they know the Pre-Shared Key (PSK), that is "the WiFi password", without actually exchanging it. With the help of the PSK, a Pairwise Transient Key (PTK) is derived. This is a temporary symmetric encryption key that is used to encrypt all further communication between the client and the access point.

So why can't you impersonate a computer already on the network by spoofing your MAC address? Because you don't know the PTK. Everything the access points sends  will be total gibberish for you, since you can't decrypt it without the PTK. Likewise everything you send will be total gibberish for the access point, since you can't encrypt it without the PTK.

For more information on the four-way handshake, I recommend Wikipedia.


Are subdomains secure from one another if they are on separate servers?

Quick answer: Probably yes

Domain and sub-domain names are just pointers to where your application resides, or at least, where it can be reached if you've put additional proxies in place.

So the real question is what stops anyone compromising any of your users at the application level?

There are plenty of exploits and developer errors to get around what browsers should enforce when communication with hosts, and attackers can always go after your servers directly.

So yes, if you screw up your application design or implementation badly enough, using sub-domains isn't going to magically save you. I would also suspect dedicated servers per customer isn't going to scale too well either, but that's a different issue.


Passing plain text passwords over HTTPS is absolutely fine. TLS makes sure it's not plaintext on the wire, so there is no issue. Client side hashing would do nothing to help here. The fact that you can get the password from the development console is expected and not an issue.
As for the concern about session hijacking, I don't get it at all. If an attacker that has hijacked a session could somehow get your password I would view that as a problem since it would allow an attacker to go from temporary access to permanent access. But sending your password untouched over HTTPS would on itself not lead to that. I think that either the person that told you this is misunderstanding something, or you misunderstood the concern. Is it perhaps related to some other wider issue?
Finally, a side note. You write that your "login for POST is over HTTPS". Are you using HTTPS just for the login? That is not enough. Your entire site - absolutely everything - needs to be over HTTPS. Just protecting the login endpoint makes you vulnerable to SSL-strip. If you use plain HTTP without TLS for parts of your website, you need to fix that.


How to securely store sensitive information?

As soon as I hear store sensitive information, I think of password managers. That is what they are made for, and some of them do it very nicely. For example the excellent Keepass allows to store additional informations associated with a particurlar account. For example, you could create a dummy account to store a Visa card number, its PIN, validity date and 3 digit key.

You can use only local storage and synchronize different databases provided they can be visible from one machine. For example it is trivial to synchronize a desktop or laptop, a tablet and a smartphone. Synchronization is indeed one of the nicest features of Keepass.

You can also have the database somewhere in the cloud, and use a random file of several kbytes as a key that you securely store on each device where you want to use it. You can even combine that key file and a password for higher security (something you have and something you know).

The only drawback is that whatever the key is, it must be the same for all devices or users if you want to share the sensitive information. And as we all know a secret that is shared between more than two persons/devices is no longer a secret. But anyway, it would not be worse than an encrypted zip file, and the key file would even add some security because it will resist by design to dictionary attacks, and even brute force will be hard to use because the entropy of the key file is high.


Is it safe to transfer location data by using TLS?

TLS encryption is obviously strong enough to protect your data.  The weakness in this question is the integrity of the keys involved.

Certificates protect the integrity of keys by making sure that no attacker has swapped a legitimate key for a fake key, and is intercepting messages in an Attacker-In-The-Middle attack.  The way certificates protect against this is by being signed by a root Certificate Authority that all computers in the communications network agree in advance to trust.  By itself, a self-signed certificate has no such integrity, because none of the participating computers knows to trust it.

There are a few ways around this issue.  The first (and safest) is to get the key signed by a trustworthy Certificate Authority, instead of being on a self-signed cert.  Most CAs charge a fee for a certificate (which can be off-putting).  Your DNS provider may offer you a few free certificates as a part of their service.  Let's Encrypt offers CA signing to anyone for free, and you can run the whole process through their API.  The advantage is that your system's security will be "normal" and your keys will be as protected as any other site; the disadvantage is the small extra effort involved in learning about the process and getting the signed certificate.

Another way is to generate your own custom Root CA.  OpenSSL can be used to generate a CA self-signed certificate, which can then be used to sign other certificates, such as your location server's certificate.  Google will return plenty of examples of how to do this in just a few calls to openssl.  Next, on all the computers where you want to trust your location server's communications, you install the custom Root CA certificate in each system's Trusted Root certificate store.  You then use the custom Root CA to sign your location server's keys, and those computers will trust them.  This seems easy, because it's just a couple calls to OpenSSL, and installing a new root certificate.  And your data and key exchanges are protected.  However, the drawbacks are larger than they seem: all the computers that trust your custom CA are now susceptible to spoofing any TLS communications if someone manages to compromise your homemade CA's private key.  (This may also be problematic if you don't have the authority to install a new root CA on all the computers involved.  For example, your workplace would likely have a security incident if your company PC had your homemade certificate installed on it.)  You can mitigate some of this risk by cautiously creating your custom CA, keeping the private key offline on a thumbdrive stored in a safe, etc., but that's a huge amount of work for very little benefit, and nothing can solve the problem of installation on an externally managed computer.

There is a third option:  look at the certificate with your eyeballs and make sure it's the same certificate you started with -- every time you use it.  While this will work, it only protects one key exchange at a time.  A year from now, if you get careless and forget to check the certificate before exchanging data, it's possible an Attacker-In-The-Middle could strike and you wouldn't notice.

A fourth option, which is where I think you were going, is to ignore the integrity of the key exchange entirely, and hope no attacker tries to intercept your communications.  Of course, if you're attacked, you'll never know.  And if you can live with that risk, why bother encrypting it at all?


best practice for encrypted filesystem inside a file

With respect to the cipher to chose -- that is aes-cbc-essiv:sha256 (the old default) versus aes-xts-plain64:sha256 (the new default) -- I've explained all this before in this answer:

How secure is Ubuntu's default full-disk encryption?

As for which filesystem to use -- obivously using a partition directly is going to give you the best performance: there's no second translation layer getting in the way between your pseudo block device and your real block device.

Since that appears to not be an option for you, then I'd recommend one of the EXT filesystems rather than one of the newer copy-on-write ones, since random-access to a large file with a COW filesystem would be messy. EXT4 is obviously the most recent and arguably most resilient of the lineage, though if you only have one large file then most of the FS features don't come in to play. So in that sense it probably doesn't matter a whole heap which filesystem you use. You're not really using the filesystem features.

As long as you allocate your file entirely at creation (as you've demonstrated in your question, as opposed to creating a sparse file), your file will be one contiguous block and the filesystem becomes largely transparent to your operation. Also, allocating your file BEFORE putting the other files on the FS will get your file closer to the start of the disk, which makes its access sometimes a bit faster.

As for security: (a) don't give out your password, (b) don't let anyone touch your computer. There's not a lot to it. Since you're running on an unsecured device, there's really no meaningful additional protection that can be put in place. If you encrypt your whole computer then perhaps you'll have something, but as it is, just be careful of how it gets used.


Is it more secure to install an application in .exe form from official website or in UWP form from Microsoft store?

If it's a huge website, well known, then they probably have good enough security, even a hash maybe, and you won't download a compromised version. If it's a not so well known website, then you are at risk.
From what I recall, when you upload an application to Microsoft Store, they check it for malware and only the owner could upload a new version (scanned as well). IMO Microsoft has a pretty good security. This is the way I would choose.


If you can have an additional TCP channel, you could use this channel for TLS and exchange (random) key material which you can use in turn for encrypting the UDP packets. Don't forget to apply a packet counter and possibly timestamps for detecting replay etc. attacks. And use AES-GCM, so you have authentication for (almost) free.

But I don't the part about getting delays because of using DTLS? We are using it in the 500 KB/s range and don't see any delay - having a complete delay of about 1 ms (which is the resolution of the used timestamp^^)


What do you do to protect data on a Macbook in the event of theft/loss of the device?

As everyone else has covered encryption:

don't put data on the MacBook in the first place if you don't need it. I use an iMac as my regular work machine, and synchronise the files I need on my MacBook when I take it out.
firmware password will make it harder for people to boot into other operating systems / recovery disks. Interestingly the FireWire drivers on OS X also deny DMA requests when the firmware password is enabled. This stops someone dumping the memory of your live laptop.
Kensington lock when you're settled into your working location.
automatic, and hot-corner-activated, screen locking requiring password to unlock. To reduce the chance that when they make off with your laptop, it's unlocked. For similar reasons, change your keychain password and set that to lock automatically too.

May as well say that I summarised a lot of this a couple of years ago in a paper for Sophos. I no longer work there.


Retrieve auto saved Skype password from Ubuntu 12.04 LTS

According to Vanilla Skype Part 2 [page 67], when you ask Skype to save your password, it takes a hash md5(username\nskyper\npassword) then it encrypts it using AES-256 and it stores it /home/USER/.Skype/SKYPE_USER/config.xml (config->Lib->Account->Credentials3).

I have just tried to copy config->Lib->Account->Credentials3 to a config.xml file on a different machine (same Skype account) and I was able to automatically login.
That can be a temporary solution while you try to solve the problem with Skype customer service.

If the password itself is of high importance to you, there are some tools (commercial) that can help you brute-force it, so if your password isn't very strong there's a decent chance of recovery (since Skype is using a fast hashing algorithm, MD5).


What are some attacks I can perform if I break into victims lan router?

Once you have admin access to a router, you have complete access to the WAN and LAN of that network. This is one reason that enterprise networks are (should be) segregated into multiple networks separated by firewalls. In that situation, all you would have gained access to is probably the "DMZ" or outer zone network.

With such a foothold, you can open up inbound and outbound ports, install monitoring on the router itself and use the router as a platform for attacking other systems further into the network.

Any enterprise router should have monitoring already installed to help identify this kind of attack, reporting it upwards to admins and the SIEM. A common scenario is for the SIEM to aggregate logs from routers to monitor for anomalies.


How did someone find my Windows username?

Your account may have been brute forced. This is when someone writes a script to (not manually, automatically) try all combinations of usernames/passwords up to a certain length.

For example, one alogrithm my start out with a then go through z then try aa, ba, ca, ... za, ab, ac, ..., zz for usernames length up to a certain number. Some/Most brute-forcers also check for the most common usernames such as "admin", "root", and common names.

If your username was short, it's much more vulnerable to brute-forcing, since the longer the password is, the more possibilities there are to the username of that length.

With crystal ball in hand, I predict your username was either a) really short or b) a common name.


Why is my Apple keep asking me to change my password for no reason? is it hacked?

This type of thing sounds to me like something somewhere has an old password stored someplace and is trying to use that password to log in resulting in the account being locked. This could be iTunes on a computer, iCloud or even your web browser or password manager if you are trying to log into an Apple related web service. It could even be some other iDevice like an iPad or iPod. If that is the case you'd have to locate what ever it is that isn't using your new password and make sure to change it there the next time you change your password.


Is using the same password for multiple TrueCrypted volumes safe?

Using the same password for multiple volumes gives an attacker more information to crack your encryption, so it is bad practice from a cryptography standpoint. Password and key re-use has historically been used to break encryption schemes in the past.

In your case I'd argue that the difference is moot, as anyone who would actually be able to take advantage of you using the same password for multiple volumes would have to be extremely sophisticated and have access to a whole lot of computing power. Anyone that sophisticated would almost certainly have other means to discover the password rather than attacking you cryptographically, they'd simply hack your computer, plant a camera in your home, etc.

It's still a bad idea to use the same password though as you're probably aware.


Nonprofit organizations asking me to email them a photo of my driver's license

Your concerns are reasonable if the server you/they are using isn't using an encrypted channel to communicate.
However, if your concerns are your private information, the security risk of an employee that takes a picture of your license and save it to his, hypothetically, backdoored computer isn't much different from using an unencrypted connection. You are just assuming that the employee is honest enough to accommodate your request to not take screenshots.


Are there any cryptographic techniques which combine encryption with false packet prevention? What is this called?

For hiding the data, you use encryption. For making sure it came from a known source, i.e. authentication use a message authentication code (MAC), or authenticated encryption. Note that confidentiality (making sure only the intended recipient can read the message) and authenticity (making sure the message came from a known source) are different!

For detecting and discarding resent packets, you usually add some sort of a counter or timestamp on the packets, and discard anything older than the previous ones. Most modern encryption schemes also take a random initialization vector that makes identical messages look different.


Is there a type of login security that is keylog and screen capture proof that doesnt require a 2nd device?

There are several variations on this theme.
One involves asking X digits, different each time, out of a longer PIN (this was used by a large online banking firm, not as their only line of defense of course, before the PSD2 era): "*?**??", then the next time you're asked "?*?**?" and so on.
Another possibility is displaying several words, and your "secret" consists in, say, a number from 1 to 5 and your password. So if your password was APQXJ and the secret was 2, you'd choose "Safe, Spot, Squid, Oxygen, Eject" - the second letter of each word will form the password. Obviously, spotting you enter the password twice would very probably give the game away unless the words were chosen very, very carefully.
A login system some friends and I set up just for the laughs a long time ago at the University employed trivia - things that no one but the user would say or know, or be able to tell with the appropriate speed. This was intended to prevent someone from even asking the real user under duress - the time taken to ask the question and get the answer would prevent the login from working. But the setup time was prohibitive (I still remember some of the questions: "Where was the shadow?" and you would have to answer, "Under the elm", typing the "U" within three seconds. There were at least one hundred such questions; mine were almost all SF trivia or quotations, and it took a weekend to set them up).
But I am not clear about your question. Are you looking for ideas, or do you need nomenclature, or do you want to know where to find a ready-made system that would do this?


It seems to me, that if I know some other person's api_key, I can get
  everything I want about him.

The same if you have this person's password. Am I wrong?

  And if I make an app, that works with this Api, I can just store these
  keys and use them anytime I want for whatever purpouses I want.

Yes, you can use the token to do anything that the user have granted to you.
For this reason, do not grant permissions to any app on the internet, like you do not give your password to untrusted people.

  Are there other ways to exploit it?

Depends on a lot of factors. Using open redirectors to steal victim's token, brute forcing the API tokens (a decent API would not permit brute force), etc.

  Is this form of login is considered safe?

If the page is loaded over HTTPS, the form posts the login and password data to another HTTPS page, and the page does not have any XSS or mixed content issues, so is secure "enough".


Separate SSL authentication and other traffic

Though I am completely at a loss about how such splitting could improve security in any sensible way, it is reasonably easy to distinguish the handshake from the rest of the traffic in a SSL connection. In SSL, everything is sent as records, with a regular format:

content type (one byte)
protocol version (two bytes)
record length L (two bytes, big-endian)
record payload (exactly L bytes)

To achieve what you want, you would look at the first header byte, which encodes the type of record: this value is equal to 20, 21, 22 or 23, with 23 meaning "application data" while the other values are for administrative processing (the handshake messages use type 22, and briefly 21 for the security parameter switching; alerts use type 20). All of this is specified in section 6 of RFC 5246.

With this knowledge, it is rather straightforward to implement a filter that sends records with type 23 one way, and records with other types another way. What can be difficult is interfacing with OS and applications; especially if you want to do that for existing applications that you cannot modify in any way. Also you will need both client and server to implement the splitting "over two separate networks".

I am not aware of any existing tool that does this job.


Struts2.3 Zero Day attack exploited: CronJob getting created

The descibed actions install a "kworker" tool on your server, which seems to be a bitcoin miner, according to Virustotal.

Since the records appear in /etc/crontab file, most likely you have installed a package with tojan on your system.

To solve this issue, I would recommend reinstalling OS on your server, as the box has been already owned by attackers and they might have installed other malware as well.


Are there sensors/devices to be used for reading magnetic bits of hard disk

Already there...

Spin stand microscopy of hard disk data mentions some varying technologies.
Single drive wipe protects data, research finds links to papers about how randomly overwriting data just once can make it unrecoverable.
Magnetic force microscope on Wikipedia. Include images taken from hard drives.


Configuring burp to use in proxy environment

Configure your browser to point to Burp's proxy details (e.g. 127.0.0.1:8080) and then configure Burp to use an upstream HTTP proxy for all target hosts (* as the destination):

However, if the upstream proxy is SOCKS, not HTTP, you need to configure it underneath (under the SOCKS Proxy heading) instead. This causes everything to be fed through the proxy. At the moment, Burp doesn't support per-target SOCKS proxies, but this shouldn't affect your situation.

For more information about Burp's capabilities, go to Help -> Burp Suite Help. Information about proxy settings can be found in the Suite Options -> Connections section of the help.


Is using JSON a secure way of handling sql queries in python?

What you want to do is used stored procedures. This is built into MySql itself. It will help prevent risks of SQL injection, and potentially speed up your application because the query won't need to be compiled and planned every time it's executed.

OWASP has a great resource about how to prevent SQL injection. Here's the relevant section to stored procedures listing their benefits and drawbacks. https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_2:_Stored_Procedures


Man-in-the-middle Blue Coat proxy SSL or what?

As other answers have already covered, Blue coat (amonngst other security products) have the capability to intercept SSL sessions for users on the network, to inspect the traffic.

What your company can and cannot do with this information depends on local laws and potentially the contract you signed when you joined the company.

If you have sufficient privileges on your local machine you may be able to remove the bluecoat CA from your trusted CA list, however all that would do would be to produce warnings in your browser as the sites you visit would then appear to have untrusted certificates (i.e. the traffic interception would still happen).

If you're concerned about what your company are doing with the information then you could try speaking to a security or privacy officer (or potentially HR) to see what the company policy is on the matter, but ultimately the only way to avoid the interception would be to use a device/connection that's under your control.


The short answer is, it depends. :) It is definitely a risk, but probably in a slightly different way to what you might expect.

A "cracked version" I suppose means somebody was knowledgable enough to modify the OS binaries so that it doesn't need the license key anymore or accepts pirate keys. But how do you know the person who disabled license verification or activation or whatever was needed to "crack" it did not add any type of malware? The OS could be doing anything with malware from the cracker, it could be running a keylogger, look for credentials to known websites, upload your data to the attacker, display advertisements, encrypt your files at some point and request ransom, make your PC part of a botnet, etc. It probably doesn't do that, at least not all the time, but still, you will never be sure.

Also it's not just the cracker itself. Cracked binaries go through dodgy storages, ftps, torrents, who knows what before you download them. As integrity/authenticity is practically never checked (at least not for security), any of those storages could have added their own malware, and this is probably an even bigger risk, because there are so many opportunities.

So no, it won't "kill your computer instantly" (whatever you think that means), but there is a very good chance that it is infected with malware (probably multiple types) and using it is not secure at all.


Do search engines verify HTTPS certificates, and if so, against which CAs?

An invalid certificate wouldn't stop search engine crawlers from indexing the dat from any website. However the Certificate configuration will have a significant impact on the ranking of the website in search results.


Repeated security questions after remote key has changed

The effect you are seeing is due to mismatching terminal settings.

Historically some systems have been using two characters to implement a line-break. First character 13 to move the cursor to the start of the line. Then character 10 to move the cursor down. Others have been using just one character to implement a line-break, that is usually character 10 which would move the cursor to the start of the next line.

When the two are mixed up you may end up with only character 10 being sent to a terminal on which character 10 just moves the cursor down.

One way such a mixup can happen is if two programs try to use the terminal simultaneously. Maybe your ~/.ssh/config file is starting some other program together with your sshcommand.


Are polyglot microservices (multiple technologies) more secure than using a single technology framework?

Unless the language itself has its specific pitfalls regarding security it mainly matters how fluent the developers are with the respective language, how much they understand they concepts necessary for security and how good they are capable they are to apply this knowledge into a secure by design software.
If there are multiple experts in their respective languages and if the tasks can clearly be separated it might be more secure to use multiple languages since the relevant expertise is (unfortunately) spread over multiple developers and languages. But apart from that a multi-language approach likely causes increased complexity of the code, makes it harder to understand and harder to maintain and limits the reuse of components - which typically makes the software less secure. So it would be preferred to stay with a single language as long as there is sufficient expertise for this available.
That said, there are some problems which are easier to solve in one language than in another. Since this also impacts the complexity and maintainability of the software the focus should also be to use the language which best fits the problem.


One word: cost.

It is much more costly to built the table than to directly try to break the password. Trying to brute-force the password requires only a trivial amount of memory; a rainbow table requires a huge storage space.

The only point of a table is that someone else has computed it and you can now use it. Many people using one table (or the same person using the table several time) pays up for the cost of building that table. If you are going a table once (for one password), there is just no point.

If every password in a given (really big) password database was using the same salt, that would be a different story. But would be a gross misuse of the salt: the point is that every password uses a different salt, so a rainbow table can never pay up.

Salting does not imply that you cannot try to break-force the password directly. Not only you can, but it is not more difficult when there is a salt. What you cannot do is reuse previous computing efforts (unless the system so broken as to not be able to generate a different salt each time).


This is a extremely generic question:
It is common to combine several minor vulnerabilities, that are not exploitable on their own, to exploit a system.
The jetty json parser happily loads any class that is named in the class attribute of a json string. And the main motivation to parse a json string on the server is to parse client data. JDBC drivers are supposed to register themselves on class load.
Another common minor vulnerability is to instantiate objects of user provided class-names via reflection before verifying that they implement the expected interface. This allows creation of all objects, that have a matching constructor, and execution of the code in that constructor.
So it really depends on the vulnerability and the control that can be exercised.
Edit
The official comment on the concrete vulnerability, you added to your question, is this:

CVE-2011-3545
Component: Sound
Access Vector: Network
See Note 2
Note 2: Applies to client and server deployments of Java. This vulnerability can be exploited through Untrusted Java Web Start applications and Untrusted Java applets. It can also be exploited by supplying data to APIs in the specified Component without using untrusted Java Web Start applications or untrusted Java applets, such as through a web service.

If that is all the information that is available, you should updated. "Access Vector: Network / web services" does not sound good.
Even worse: If your server has a web browser with Java installed, someone might be tempted to use the web for trouble shooting. This vulnerability is exploitable by visiting infected website without any user interaction (drive by download).


YES there is a risk introduced by including the session identifier the HTML code as it will make it easier to exploit XSS vulnerabilities to hijack sessions.

First, accessing session id from JavaScript is BAD PRACTICE, cookies should have the HTTPONLY flag to prevent that.

In your case, even if the HTTPONLY flag is set, having the session identifier in page body makes it easier to access this identifier while exploiting the XSS and thus bypass the HTTPONLY.


Preface: Without insider knowledge, it is equally likely that a company with security incidents in the past:

is better prepared for the future
will continue to have problems in the future

While an analysis of company's response to a security incident might reveal some clues about their preparedness, it can also indicate strengths or weaknesses in areas other than security itself (mainly public relations). It extends to the frequency, severity, response time.

Without full insight their assessment might lead to wrong conclusions.

Personally, I would put most trust in a company/team/system with a significant, decreasing number of well-handled near misses--an information that won't be officially publicised (unless in retrospective).

  Where do I start to learn more about a given company's or software solutions' security track record?

This question boils down to "how do I choose a business partner in a free-market economy?" If you are concerned about the security, you start by:

navigating to the main page of an Internet search engine (like duckduckgo.com, google.com, bing.com)
typing company_name security into the search field
important clicking on the News hyperlink above the search results
reading media reports related to the company, service, product in question, taking into consideration reports from the entities you trust most
iterating with different search queries: company_name breach, company_name safety record, service_name security, product_name security etc.

In short (and in theory) in a free-market economy it is the role of independent media to gain the information (including insider) and present to the public with an analysis. It is however up to the public to whom it trusts.