Bluetooth/WiFi Identity tracking in public spaces - How to discover? Your unique mobile device WiFi MAC addresses as well as your Bluetooth unique address can give away enough information to identify you and track your location in public spaces even if you don't establish a connection. There are various security concerns about this. For example in the article

https://medium.com/@roryireland/is-dublin-airport-tracking-passenger-phones-without-their-permission-8a779453a6d7

there is a discussion about the Dublin airport using such information to track queues, which however could be misused by authorities to track individuals. The same applies to other public spaces like Shopping Malls etc.

Since this tracking would be mostly passive could there be a way to know that you are being tracked by signals your WiFi or Bluetooth are emitting?

I don't think there is anyway you could know that it is being tracked.  If you have Bluetooth and/or WiFi turned on, you would have to assume that it is possible that they can be tracked.

If this is an issue for you, the only solution is to turn off Bluetooth and WiFi in public spaces.


What are the security implications of enabling a SNI-hole on a web server? A web server (let's say Apache 2.4) implements SNI. It is configured with a 4096 bit SHA384-signed Wildcard Certificate (*.land.org) with a Subject Alternative Name (land.org). The Certificate Authority has a trusted path to a SHA-2 signed root certificate as well as a second trusted path to a SHA-1 signed root certificate. Let's also say that this web server implements what is currently considered to be secure renegotiation.

The web server is configured for a default Virtual Host (wonder.land.org) with only SSLv3 enabled, with an SSL certificate containing a unique DH1024 key and all of the ancient, insecure ciphers in the book (112 bit down to export ciphers, etc. - so accommodating that even Netscape Communicator would be happy). The other Virtual Host is land.org with TLSv1.2 and TLSv1.0 enabled, with 128+ bit ciphers and a unique DH2048 key. The cipher orders for both Virtual Hosts are from strongest to weakest based on known vulnerabilities and cipher strength.

Bob is a user with a modern browser supporting TLSv1.2 Elliptic Curve encryption with contemporary paranoia. He accesses https://land.org on a daily basis.

Alice is a museum curator at the Smithsonian using with an ancient web browser supporting export encryption over SSLv3. She accesses https://land.org on a daily basis to make sure the 10BASE2 connection is still working on the 486DX2. Since the web browser doesn't support SNI, Alice's request falls through a "SNI-hole", returning the default Virtual Host (wonder.land.org), which is a static HTML 2.0 page stating "Your web client does not support Server Name Indication and is vulnerable to a poodle attack. Please consider upgrading your museum exhibit. However, your internet connection does indeed work."

Question (Yes/No): Does this web server compromise Bob's security, or its own (the server's) security? Consider only currently publicly-known vulnerabilities.

My gut feeling was that I would rather direct the SNI-less connections to a different server (not the same one serving Bob), and via means that are external from the same server.  Something like a Deep Packet Inspection firewall actually looking at the ClientHello versions and the SNI part.

I can see two reasons against SNI-hole being parsed in the same server:

1) TLS Server Name Indication and Host headers are completely different features at different protocol layers, but serve a very similar purpose. Because of this, it may not be in the interest of server software creators to interpret them differently - and it might be somewhat difficult to keep testing that the behaviour of selecting the virtual host is happening at the TLS SNI level - so at a future upgrade, Bob might end up at the unsafe server with a cookie that was not supposed to be sent via this method (or Alice might receive an error instead of a relaxing explanation about her connection.)

2) By keeping all the weak ciphers and protocol variations in the same server you keep the server software complicated, and possibly open for so far unknown attack vectors somehow able to revert/rollback to unsafe versions of the protocol.


Forwarding traffic to SSLSplit from Android I want to forward non HTTP traffic to SSLSplit in order to do a MITM attack. How would I forward the traffic to SSLSplit from my Android?

I've had good success with the following Android proxifiers:

ProxyDroid
Postern

ProxyDroid has one draw-back; your phone must be rooted. To the best of my knowledge Postern will work on an un-rooted phone.


Personal stylesheets In reference to this question, I was researching whether or not there would be any security risks in letting users add their own stylesheets.

He brings up a scenario in which a dev might use positions to replace the search and password field. If however, the custom CSS was only seen by the user that added the styles, then are there any other risks?

Even with the expression()? Because I do not know why someone would try to XSS themselves.

Try not to see security from the developer's point of view, but instead, follow a set of best practices. For example, you will be accepting input from a user, in the form of a file upload or text input, sanitize the content nonetheless, look at the answers to this question for tips on how to sanitize user defined css.

I would not assume that the css may only come from the user who will see it, this is most likely the current requirement, but I would not be surprised if in the future, a series of changes would allow this restriction to be bypassed.

Also, depending on the implementation (for example if you serve a url to a css file) someone may be tempted to try to just change all the urls for a malicious one (http://good-site.com/user1.css --> http://bad-site.com/?inject=user1.css), think XSS, injection, etc...

In short, my advice is to implement all security measures available given your project constraints.


What are the pieces of information delivered in a user profile at the end of a OpenID Connect flow? From what I understand about using OpenID Connect (over OAuth2), is that we end up with some JSON containing information about the user. That information is transported as a JSON Web Token.

➥ What are the pieces of information specifically?

User’s email?
User’s mobile phone number?
User's human name?
User’s “username” on some system?
Some kind of unique identifier?

Looking through the OpenID Connect site, such as this page, mysteriously I cannot find any explanation of the payload at the end of a OpenID Connect transaction.

If multiple pieces of private information are provided, is there a way to ask for authorization to provide only a subset such as email address but not phone number, just like granularities of scope in a OAuth2 request for delegated authorization?

Most of what little I know about OpenID Connect came from the video presentation, OAuth 2.0 and OpenID Connect (in plain English) by Nate Barbettini of Okta.com. He explains the mechanisms & protocols very well, but did not touch on the actual content/payload.

You were almost at the right resource!  If you click the core link on the page you referenced you'll find all the answers you're looking for.

There is a section on the ID token which contains the claims (attributes) that are defined by the OpenID connect spec.  The only one that matches up to you list is the sub (subject) which is a unique identifier for the user.

So where are the rest?

The spec defines a set of standard claims that match up to the attributes you've mentioned.  In fact, the ID Token is intended to be extensible.  As such you can add whatever claims you like to the token.

Requesting access

The mechanism for adding various claims to the provided ID token is done (as you've suggested) using scopes.  Most authentication servers allow the creation of rules that govern which claims are requested by each scope.


Cloud-based DDoS as a Service With the consolidation of cloud computing and virtualization, a really simple doubt comes to my mind: why isn't DDoS being largely offered as a service? Why don't we see cloud-based DDoS attacks?

vDOS, LizardStresser and others offered a way in which you could pay to attack a target but they used their own infrastructure.
It seems safer and simpler to just charge a client, use part of that money to rent servers on an IaaS provider and build a cloud-based botnet. That way one could start an attack from inside the provider to a specific target without even using their own structure. This could even be used for spoofing of attacks in general. Is there any particular reason why this doesn't happen?

I have no idea how difficult it is to build a botnet in either context (standard or cloud-based), if getting caught in the cloud would be easier or if this could just be a matter of profit.

Thanks in advance.

... but they used their own infrastructure

It's not really their own infrastructure what they use. They use instead botnets consisting of  hijacked systems. These are systems which they p0wn but definitely not own. And thus it is very cheap for them.

Apart from that any VPS provider who would rent their VPS for DDoS attacks would quickly lose reputation and thus proper customers. And if a VPS provider then specializes on providing VPS for DDoS attacks to make up for the loss of normal customers it would be more easy to block such DDoS because they all origin from the same networks, i.e. simply cut off this provider from having access to major networks.


Did google start using proxy for gmail images? Normally, whenever someone sends an e-mail to someone else, some measures can be taken in order to track the reciver's IP; if the receiver and only the receiver gets the image, you can easily tell his IP.
I did notice something with google:
whenever I get an image in GMAIL, and I check the URL, I see this:

https://ci5.googleusercontent.com/proxy/longstring#realImageURL

I think this is something new with google, which disables this kind of attack. notice the /proxy/ in the address above. what do you think? can someone confirm? are they using proxy in order to prevent this kind of attack?

From what I know is that Google deployed image proxy servers in 2013.

Here is an old news about that https://wordtothewise.com/2013/12/gmail-deploys-image-proxy-servers/

  Sometime very recently (last 24-48 hours), we are seeing that Google made a change to Gmail such that all image URLs in the email
  content are replaced by a call to Google’s content caching service
  googleusercontent.com.

  For example, an image with the src: “http://mysite.com/i.jpg” will be replaced by Gmail with a URL something like this:
  https://ci3.googleusercontent.com/proxy/…#http://mysite.com/i.jpg


How does torrent poisoning work? Can someone explain how torrent poisoning attacks work? I am looking for some tutorials on how to do it. What are the countermeasures that someone can use to defend themselves against it?

Torrent poisoning means that peers join the swarm which don't contribute to it and only use up resources.

One method is an evil peer which claims to be seeding the whole file. However, instead of returning valid data, it returns garbage. The clients won't notice this until they received the whole chunk and verified the checksum, which means that they wasted time and bandwidth. Another variant is to accept all requests, but then not send any data at all until the connection times out.

At the same time, the bogus peers request chunks from legitimate seeds even though they don't need them. This takes up bandwidth and connection slots which would otherwise be available to legitimate peers.

By flooding the swarm with a large number of such peers it can become impossible for the leachers to find any real seeds to obtain legit chunks of the file.

This can not be prevented tracker-sided, because each of these interactions is directly between peers. A mechanism for reporting such abusive peers to the tracker or a 3rd party would be counter-productive because it could be abused by the malicious peers to accuse legit peers and knock them off the network. The only possible countermeasure is to have the bit torrent client identify the IP addresses of malicious peers and block any connections with them.


Why not 1FA with Google authenticator instead of passwords? Why are passwords needed at all if the user signs in using a code from Google authenticator?

I guess the first argument could be simply it being "single factor" once again. If you are using single factor authentication the password is the most convenient factor for people to use considering you do not need additional hardware and it is easy to implement.

Also a password is "easier" to store securely compared to a token. The token's security is completely reliant on your device security, it may seem trivial to you that you keep your phone safe (PIN code, encryption, etc...) but that might not be the case for all people.

I know the counter argument here is that in general people use password managers which must be kept safe equally or that, in case they don't, the password might be weak. But bear in mind that not everyone has a smartphone or might have the best security hygiene, in such cases the password is still the easiest to adopt since all you need is your brain to remember it.


Difference between Hybrid encryption and Diffie-Hellman key agreement? Can someone explain me the difference between the Diffie-Hellman key agreement (DH encryption) and Hybrid encryption?

As to my knowledge DH key agreement uses public and private keys to generate a session key between two parties and uses that session key to encrypt the data. Isn't this the mechanism used in Hybrid encryption as well?

Hybrid encryption uses public-key cryptography to exchange a secret key, and symmetric cryptography to encrypt the data. The main reason is that public-key cryptography makes the key exchange easy, while symmetric cryptography is faster.

The Diffie-Hellman key exchange is a protocol used along with public-key cryptography. It allows 2 entities to create a shared secret (i.e. the session-key). The DH key exchange will not encrypt your data! It will only give you a key that can be used with a symmetric-key algorithm to encrypt the data.

Basically, the DH key exchange is one of the tools used in the first steps (the key exchange part) of Hybrid encryption.

PS: I found a related question on the Crypto community, you might want to take a look:
"Why is Diffie-Hellman considered in the context of public key cryptography?"


TLS reliance on System Time I'm interested to know if there is any reliance on system time (as defined by Linux or windows) when initiating a secure handshake. I'm aware that TCP typically uses a random number (RFC 1323) to provide a time stamp for message ordering, however I'm not sure of the TLS utilisation of system time. You can imagine this question being applicable to two system wishing to establish a secure connection but don't share a synchronised time.

Cheers

Mark

During the handshake, the client and server send each other "random values", which are sequences of 32 random bytes. The "client random" is part of the ClientHello message, while the "server random" is part of the ServerHello message.

In both cases, the first four bytes of the random value encode the current date and time (number of seconds since January 1st, 1970, 00:00 UTC). The reason why they do so is a bit unclear and has been lost in the mists of Time. The best explanation we can come up with is the following: if the client or server does not have a good source of randomness, then at least the inclusion of the time will make sure that they don't reuse the exact same "random" value. Of course, lack of a good random source is likely to induce other weaknesses (e.g. if using RSA-based key exchange, the client generates the random pre-master key, so the client MUST have a strong PRNG at hand).

In order to validate the server's certificate, the client should have an approximate knowledge of the current time, since certificates and CRL have expiry dates. This does not require that the server knows the current time; neither does it need any precise synchronization between client and server.

It has been argued that SSL can be (ab)used as a way to obtain the current time: simply connect to a SSL server; do the full handshake so that you know that you are talking to the right server; use the server's notion of time (from the first four bytes of server_random as current time). This is not reliable. From my own measurements, about 15% of deployed SSL servers are either wildly off (by years), or simply don't follow the standard and use random bytes for the first four bytes of server_random. In any case, a client shall not use the server time for purposes of validating the server's certificate: the client must validate the certificate to be sure that it talks to the right server, and the client must be sure that it talks to the right server to be able to trust that the received server_random really comes from the expected server and thus contains the right time. There is an intrinsic chicken-and-egg issue here.

From the raw SSL/TLS protocol point of view (as specified in RFC 5246), certificate validation is out of scope: the server sends some certificates to the client, and, somehow, the client gains knowledge (with some high degree of certainty) of the server's public key. In practice, clients do that by performing certificate validation, which requires (at least) a notion of current date. This need for a local clock is a known problem for embedded systems (at least, for embedded SSL client that cannot contain an hardcoded copy of the server's expected public key).


What is the user's private key literally used for in a digital certificate? As far as I know, before entities acquire a digital certificate from a CA, their app will generate a pair of keys (PRk and PUk). But what is the private key used for?

P.S. Is user's public key is the same as CA's?

(The reason to ask this is because after CA issues the certificate it will use its private key to do the encryption, but how to decrypt it? )

The CA signs your public key, proving that whoever has the private key that works with that is really you.

Hence, the CA never sees your private key. Which is good, because your private key must stay private.

Won't answer the "what is a private key for" question, since it is just a basic question of understanding private/public key infrastructure, and you can find that explained in very many places.


SSL Certificate revocation check In the SSL protocol I don't see where the certificate is checked for revocation status.

https://developer.mozilla.org/en/Introduction_to_SSL

Is the Certificate Revocation and Status Checking not implemented in the SSL protocol ?

The SSL protocol specifies the way a server sends its certificate to the client. The client should then "obtain" the server public key by validating the certificate. The SSL specification does not describe certificate validation; for that, you must look at X.509, in which you will see that it is a much more complex process than what is described in the document you link to.

Checking revocation status is part of certificate validation. The client is actually free to do it in any way it sees fit; many web browsers "check" revocation status by a process which goes like "mmhh... it is probably not revoked anyway, no need to check anything". In the X.509 world, revocation status can be ascertained by downloading and validating CRL (Certificate Revocation Lists) or obtaining OCSP responses from OCSP responders (an OCSP response is a kind of CRL reduced to a single target certificate). Theoretically, revocation status should be obtained for all certificates, i.e. the server certificate but also the intermediate CA certificates used to validate the server certificates, and all other certificates used to validate CRL and OCSP responses (this can become highly recursive). The aggregate cost (especially in download time) can become prohibitive, which is why many client rely on a weaker but faster model (e.g. checking status only for the server certificate itself, not the intermediate CA; or checking no status at all).

Anyway, validation is how the server public key is obtained, so it occurs during the SSL handshake, right before the ClientKeyExchange message is sent by the client.


What is the relationship between the GPZ research titles and Meltdown and Spectre? I learned today that there were three vulnerabilities reported by Google Project Zero: bounds check bypass, branch target injection and rogue cache data load. Here is the AMD response to them: https://images.idgesg.net/images/article/2018/01/amd-response-to-kernel-bug-100745803-orig.jpg

However, on Wikipedia I see that there are two vulnerabilities, Meltdown, an easy-to-exploit variant affecting Intel and Spectre, a hard-to-exploit variant affecting also AMD.

What is the relationship between these three Google Project Zero research titles and the two Wikipedia pages? Which of these research titles belong to Spectre and which belong to Meltdown?

If I understand you correctly you ask how the three issues shown by GZP map to the names Meltdown and Spectre. You'll find the answer at the beginning of this post from Google Zero Project:

  So far, there are three known variants of the issue:

  Variant 1: bounds check bypass (CVE-2017-5753) Variant 2: branch
  target injection (CVE-2017-5715) Variant 3: rogue data cache load
  (CVE-2017-5754)

  Before the issues described here were publicly disclosed, Daniel
  Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael
  Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas
  also reported them; their [writeups/blogposts/paper drafts] are at:

  Spectre (variants 1 and 2) Meltdown (variant 3)


Why do we receive contact form spam with random characters? For the last two weeks we have been receiving a form of spam through our website contact form that I haven't seen before.

It looks like this:

Name:   iYvNgmpTLwxqaCj
Company:    lqidQuVNMhIJsz
E-Mail: peter.pan@example.com
Country:    Please select...
Phone:  5217200934
Address:    OsHSnquoU
Privacy Policy accepted:    iaccept

Message:
MCGELokRdhvTQYK

The spammer's inputs to form fields are the parts after the colons.

Note: I have changed the mail address. It looked like a legitimate mail address of a larger company, e.g. First.LastName@company.example.com. That is always the case.

Every other field contains random strings of ASCII characters. The phone number seems to be a random number. The privacy field is populated from a checkbox.

Another fact is: We always receive exactly two of these messages at the same time. Not more, not less. The frequency is on average 1-2 attempts per day.

Does anyone have any idea what the purpose of such a spam message is?

Previous similar questions:

Spam with random strings: Very similar style, but the key difference is that our spam does not contain any html of bbcode tags. So the answer doesn't fit.
What is the point of gibberish spam: While the term gibberish certainly applies, our spam does not contain any words.

My ideas:

The thing I could think of is password bruteforcing, in that the bot doesn't notice that it is on a contact form and instead just tries to log in with a mail address and random password. However, the chances of this working are astronomically low, given the general odds and the low number of attempts (two).

Further information
After a while of dealing with the spam, here are some additional pieces of information:

While I initially reported 2 spam messages per try, in fact the bot tried 62 times. Most were blocked from sending because a "privacy policy accept" box wasn't ticked. This indicates, that:

It was indeed a bot, because the website front also prevents sending the form without the box ticked (client-side).
Check- and radioboxes are probably randomly selected

If the privacy box was NOT ticked, the form also contained no other content (fields empty).
Per 62-tries attempt, the same IP was used. In later attempts a different IP was used.
As Seb_Schulz suggested, I ran the mail addresses through HaveIBeenPwned, but most of them didn't turn up. So maybe it's from a new leak. However, it might be that the addresses are not valid. While the domains all exist, I mostly couldn't find the particular person associated (e.g. if domain is a university with public list of people).

Prevention
Since we didn't want to implement Recaptcha as our site is otherwise Google-free, we tried two mitigations of simple captchas.

We put in a question, e.g. "Select picture of the famous person xy", with two radiobuttons with pictures next to it. The user had to select the correct image. The correct one was the second radiobutton. This did not work, presumably because the boxes were randomly selected by the bot.
We replaced the question with a simple math question, e.g. "Please solve 4 + 2 = ", with a simple text input field. The question even always uses the same numbers. This works for now. I suspect, the bot would fill in its random characters into the box, which is obviously not the correct number.

I hope this helps someone.

The thing I could think of is password bruteforcing, in that the bot doesn't notice that it is on a contact form and instead just tries to log in with a mail address and random password. However, the chances of this working are astronomically low, given the general odds and the low number of attempts (two)

Your idea isn't so bad. It may be 2 attempts a day to bypass the common 3 attempt lockout policies.

  Note: I have changed the mail address. It looked like a legitimate mail address of a larger company, e.g. First.LastName@companyname.com. That is always the case.

Further proves your point. Try running the address through haveibeenpwned.com and see if it occurred in a breach. If so, you may deal with a case of credential stuffing.


What would be the best way to authenticate a user in an offline, multi-user mobile environment? I'm currently working on an offline authentication system for a multi-user mobile environment.

In order to avoid storing all passwords locally, which seems to be a bad idea, I proceed this way:

A first online authentication is required. the server then returns a token to the user, which will be used to perform future API calls.

In order to have several users on the same mobile/tablet, I need a way to store several tokens, and only let access to a particular user.

two solutions come to my mind:

classic password, with the risk that the user enter the same password as their "main password"
PIN code or similar code, without relation to the "main password" but less entropy

Fingerprint authentication would also be a solution, but not all device support fingerprint  detection.

Both cases have drawbacks and both are weak, as they are vulnerable to offline attack

What would be the best way to authenticate a user in an offline, multi-user mobile environment?

Well, you can just invalidate the token and delete it whenever you want to switch users or otherwise "log out" the user, than use the online authentication with the online password check.

The only way to reliably protect a token from offline attack (as far as I can tell) is to encrypt it, which would require a password or pin. You should use a slow password derivation function with enough iterations, such as PBKDF2 to help with the entropy a bit.


How does processor architecture affect password hashing speed? Does hashing speed vary significantly using different architectures (x86 vs ARM)?

Scenario

I am investigating the possibility of using a cluster of Raspberry Pi for cracking passwords hashed with bcrypt or scrypt.

As the Raspberry Pi use a CPU chip based on the ARM architecture, I am wondering if that affects matters much.

ARM processors are a 32-bit architecture, and are relatively inefficient at doing 64-bit arithmetic operations: when they must compute a 64-bit addition, they must do so with two 32-bit additions and some carry propagation. This is somehow equivalent to x86 used in 32-bit mode (except that recent enough x86 have access to SSE2 opcodes, which offer computations on 64-bit integers, even in 32-bit mode). All recent x86 can run in 64-bit mode (if the operating system allows it), which makes them much faster at computing hash functions which rely on 64-bit arithmetic operations, the prime example being SHA-512. On a 32-bit hash function like SHA-256, ARM and x86 cores will be "comparable".

An additional twist of ARM is that it has several instruction sets; the original ARM used 32-bit opcodes, while newer versions allow for the "Thumb" instruction set which has smaller, but less powerful opcodes. "Thumb" has been then extended into "Thumb-2", with a mixture of 16-bit and 32-bit opcodes. The newest ARM cores know only Thumb-2. "Thumb-2" code is supposed to be almost as efficient as the original ARM code, while being noticeably more compact. But a lot can hide in a word such as "almost".

For bcrypt, what matters is the availability of about 4 kB of "fast RAM". Almost all ARM and x86 cores you will encounter have L1 caches which are larger than that (to get a cache-less ARM, you have to look at 33 MHz ARM7TDMI or similar systems), so, then again, ARM and x86 will be comparable.

For scrypt, the situation is mixed. Scrypt uses an internal hash function to compute seemingly random accesses in a large RAM buffer, so this is a race between the time to compute the hash function on a small input, and the latency of the main RAM. Main RAM latency does not scale (and a "faster" bus means more bandwidth, not less latency). For a small ARM-based system like the Raspberry PI, the hash function will be the bottleneck, especially if it is SHA-512. For bigger multicore x86, the memory latency will make the whole thing slow. The x86 will not give speedups proportionate with its larger price; especially if using CPU with 6 or 8 cores: there will be too much contention on the shared memory bus.

That being said, the question is about economics: what architecture choice will yield the most hashes per second, for a given budget ? This includes the cost of hardware, but also the energy, which, in the long term, dominates (you pay the hardware once, but you must feed it with electricity all year long). Energy costs must include cooling systems, which are not negligible in big computing farms. ARM processors are reputed to use less energy (it has long been their selling point, and that's why smartphones use ARM processors nowadays).

So the ARM architecture should be, on average and for large clusters, a better choice for password cracking, except when dealing with a CPU-bound hashing process (like PBKDF2) which relies on a 64-bit hash function (e.g. SHA-512), in which case an x86 CPU (in 64-bit mode) will be a better deal. This will change with the advent of 64-bit ARM processors.

For an amateur who does not build a cluster beyond what fits in his room, and must use off-the-shelf hardware, these issues will be dwarfed by those of availability and market effects. You do not buy a lone x86 CPU; you need a motherboard and other things around it; ultimately, you buy a PC. The cost of the CPU will be a small proportion of the total hardware cost. Similarly, you do not buy an ARM, but a Raspberry PI. Therefore, to get a correct estimate, you must perform benchmarks. For raw hash functions, I suggest using sphlib, a library of implementations of various hash functions (including SHA-256 and SHA-512), written in C; it comes with a benchmarking tool. For bcrypt and scrypt, peruse the reference implementations.

(As a gut feeling, I expect a draw. The Raspberry PI cluster will, of course, totally win against the x86 cluster if you take into account the "fun factor".)


Why aren't installer isos gpg signed? When downloading a Linux installer iso, the user is supposed to check the iso with sha or m5sum and compare the result against a checksum file, and then check the gpg signature of the checksum file.
If I understand it right, the checksum is to test for iso integrity (iso not corrupted) and that gpg checks that the checksum was not manipulated. So why is the iso itself not signed?

It's faster and easier for the vast majority of users to just use sha1sum or md5sum than to import the GPG key and check it.
And if an attacker could change the hashes on the official site, the same attacker would be able to change the keys there too.


Secure REST API and Single Page App by using external OAuth 2 Authorization Code I am trying to understand how to implement an OAuth 2 Authorization Code flow when having both a single page JS app and a REST API. The aim is to secure access to the REST API by offloading authentication to the OAuth provider.

Currently my flow looks like:

1)

+--------------------+               +----------------+
| JS Single Page App | - redirect -> | OAuth Provider | - user enters credentials
+--------------------+               +----------------+

2)

+----------------+                                   +----------+
| OAuth Provider | - redirect with temporary code -> | REST API |
+----------------+                                   +----------+

3)

+----------+                                      +----------------+
| REST API | - request access token using code -> | OAuth Provider |
+----------+ <- return access token ------------- +----------------+

What should I do now? My current understanding is that I should redirect the user upon receiving the access token to a page that will load the JS single page app again. But should I share the access token with the single page app and use the presence of it to authenticate any request hitting my REST API, or is better to create a separate identifier and maintain a server-side mapping between new-identifier->access_token? Either way what would be the best way of transferring whichever identifier to the client? I would prefer not maintain any session and not have the identifier turn up in the URL bar of the redirected page. The only thing I can currently think of would be to create a temporary cookie that the single page app would read and then erase, but somehow that feels a bit clunky.

Firstly, and to be very clear, OAuth 2 is not an authentication protocol. If you wish to know the identity of the user, there are other protocols designed to solve this problem, such as OpenID Connect. If you intend to use OAuth 2 for the purpose of authorizing access to your protected resources, continue reading.

To answer your direct question: you appear to be using the Authorization Code Grant flow:

 +----------+
 | Resource |
 |   Owner  |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier      +---------------+
 |         -+----(A)-- & Redirection URI ---->|               |
 |  User-   |                                 | Authorization |
 |  Agent  -+----(B)-- User authenticates --->|     Server    |
 |          |                                 |               |
 |         -+----(C)-- Authorization Code ---<|               |
 +-|----|---+                                 +---------------+
   |    |                                         ^      v
  (A)  (C)                                        |      |
   |    |                                         |      |
   ^    v                                         |      |
 +---------+                                      |      |
 |         |>---(D)-- Authorization Code ---------'      |
 |  Client |          & Redirection URI                  |
 |         |                                             |
 |         |<---(E)----- Access Token -------------------'
 +---------+       (w/ Optional Refresh Token)

This flow is optimized for confidential clients: clients which can keep a secret from the end-user and any third-party that might be trying to gain access to the protected resources. In the case of a javascript application running in the client's browser, you cannot keep a secret - all the code is there and simply breaking into it with the browser's debugger reveals all the secrets.

Instead, there is the Implicit Grant flow, specifically optimised for clients like yours. The RFC even uses JavaScript running in a browser as its example of a client intended to use this flow.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier     +---------------+
 |         -+----(A)-- & Redirection URI --->|               |
 |  User-   |                                | Authorization |
 |  Agent  -|----(B)-- User authenticates -->|     Server    |
 |          |                                |               |
 |          |<---(C)--- Redirection URI ----<|               |
 |          |          with Access Token     +---------------+
 |          |            in Fragment
 |          |                                +---------------+
 |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
 |          |          without Fragment      |     Client    |
 |          |                                |    Resource   |
 |     (F)  |<---(E)------- Script ---------<|               |
 |          |                                +---------------+
 +-|--------+
   |    |
  (A)  (G) Access Token
   |    |
   ^    v
 +---------+
 |         |
 |  Client |
 |         |
 +---------+

You should read the RFC for details of how this flow works, but the general concept of the flow is to no longer require the use of an authorization code; instead the client is directly given the access code.

This comes with the drawback that when the code is no longer valid, the client must request the resource again - there is no way to "remember" the authorization grant for a client which is unable to keep a secret. This is an intentional decision made by the OAuth authors to improve the security of clients of this nature.


How do some sites detect AdBlock Plus? For example this one disables function if AdBlock plus is detected, and it works. Is there a way to circumvent this?

There are many scripts and projects to help site owners detect AdBlock Plus, but I think you're interested in how they work.

The idea is simple. The website loads a JavaScript file called ads.js (or any other name that AdBlock Plus finds "attractive"), which contains:

var amIHere = document.createElement("div");
amIHere.setAttribute("id", "amIHere");
document.body.appendChild(amIHere);

If you have AdBlock Plus, then it will block this script from running and the div won't be created. Then they use a normally-named JavaScript file which contains a simple check for the div's existence

if (document.getElementById('amIHere')){
   alert("You're Alright");
}else{
   alert("You're using AdBlock Plus");
}

Other methods is to load a div with the id ads or that has a class text-ads which AdBlock Plus detects as ads and tries to hide, then using JavaScript check if the div is hidden or not.

This will help you detect the majority of AdBlock Plus users, but because of the nature of this problem (everything happens on the client side), in theory, a user is able to circumvent all of your checks and detectors.

As a "power user", when a website I need to use tells me that I have to disable Adblock Plus, I just disable it and enable it after I finish. I don't really want to spend time and resources to find a way around it. So you can assume that the vast majority of your users won't bother. They will be annoyed that you're forcing them to disable it, but they'll either leave your website or just disable AdBlock Plus.


How to secure consumer info without buy an certificate? I need to know how to properly secure my consumers credit card info without buying expensive certificates?  It is possible to use https:// and ssl or tls without an certificate and without scary warnings from browsers ?
If yes what is the safest way ?

I need to know how to properly secure my consumers credit card info
  without buying expensive certificates?

RapidSSL certificates are as cheap as $49/year. Furthermore, properly securing credit card information requires a lot more than just using TLS and having a CA signed certificate.

If $49/year is a lot of money to you then I don't think you have the resources to properly store credit card data in a secure and compliant way. Presumably you are using free or very cheap web hosting which means you probably have a shared hosting environment with limited control over your firewall, logging, and other potentially malicious users on the system.

Having such limited resources does not mean you can't accept credit card payments, just don't host the checkout or store credit card details yourself. Check with your bank to see if they have a hosted gateway product, or look at something like Stripe Checkout or PayPal express checkout.

These will allow you to accept credit card payments without needing to use TLS (although I still recommend that you do), because your system will never come in contact with credit card data.


Security Protocol Notation Editor Are there any editors or tools that support the
secure protocol notation?

Any TeX editor could do it without breaking a sweat.  There's a list of them here.


What prevents "money card" (offline smartcard system) from getting duplicated for payment fraud? I don't know how well known this system is or maybe there are equal systems better known international. So I'll introduce the related points of the system:

It is a paymentsystem where your wallet is saved on the cardchip itself. The terminals you are able to pay with such a card on do not have to have a permanent internet connection.

And even if they have, the system isn't designed for synchronisation on real time. It has at least intervals of multiple hours (AFAIK even just 1 time per day) where the moneychange gets updated.

So if such terminals aren't sharing there information of moneychange in any kind of netwrok to other terminals, what is preventing a bad guy from just duplicating the chip and its data and paying with each chip on a diferent terminal? As the available money is just stored on the chip how could a terminal know that the represented ballance is invalid? Or even the chip it self is?

Of course in the synchronisation process it will get noticed. But untill that a lot of time can elapse

I could figure out some informations about the smart card it self.
The chip isn't just holding binary data which every terminal is able to access. The chip contains a micro controller which can get its own firmware set up. So the terminals aren't communicating with the stored data, they just have a API to the microcontroller.

So if you want to copy the data, you have to request the mc to read the data for you. What he ofcourse will deny.

So the other way is, to physically produce a identical chip containing the same controller with the same firmware running on, made for that chip. because only that chips own mc is able to access its binary data and read it correctly. (What sounds almost impossible to me. Even if not, the amount of money won't be enough for the work this would effort)

Or the other option for doing so is: get the controller seperated from the binary data, without destroying it. and hack the encryption he stored the data with, to be able to write plain data in the chips memory.

Without hacking the encryption we could try to shortcircuit the mc...

Even to short circuit the mc wouldn't work, as the money using terminals will use the API to the controller and are also not accesing the data directly.

And I would bet, you can't short circuit the mc, access the data directly and then set back the undamaged microcontroller, without at least making it invalid by some secruity flags or such kind of stuff.

Also notable is that the terminals in generell are just able to decrease the money amount. Such that are able to increase the money are hold by the bank it self and not given out. So they are probably on a way encrypted, that the chip contains a public key which keeps some information about how the "money decrese" has to be encrypted. What would missmatch in case of a increase.

That was all I figgured out, and I would guess this is enough to be an answer even in some one else eyes.


Entering passwords at public computers Sometimes it happens that I have to access my email or some other web service from public machines. Are there any options to make it secure or at least reduce risks to acceptable levels? I am most worried about keyloggers. But even if can copy-paste password from somewhere there are still tools to intercept that. So there is basically no security by definition? One measure I can think about is two factor authentication, but it is not always available (for every service). Other possible measure is to have a server/machine somewhere and access it using some sort of remote access, but this requires considerable resources.

The usual recommendations about accessing private data from a public computer are:

Don't do it.
Don't do it; instead, use a smartphone or tablet.
If your really must do it, there is no other choice, it would be life-threatening not to read your email, then the following mitigations can be used:

Use two-factor authentication (e.g. with Gmail), the second factor using your phone (presumed safe).
Use One-Time Passwords.
Change your password from a "safe" computer as soon as possible after the access.

The first two mitigations suppose that you can enable these extra authentication methods on your Webmail, and that you have some extra device with you (a phone to send or receive a password by SMS, a generator for one-time passwords, a printed list of your next 20 one-time passwords...). The third mitigation depends on how soon you may access a safe computer, but, of course, if you can use a safe computer within the next five minutes, then why don't read your emails from that safe computer ?

In any case, whatever you do, you are betting that possible attackers won't hijack your connections automatically; instead, that the attackers passively gather passwords and won't do anything else immediately, leaving you with some minutes or hours to "plug holes". There are some attackers who act that way; but there also are other attackers who recognize connections to various Webmail systems and automatically hijack them. So, really, don't do it.


Transactional replication through VPN, do I need to encrypt connection? New to security.

We are planning to setup SQL Server transaction replication over a VPN to Azure over the internet.  The source server is inside our data center and the target will be a managed instance in Azure.

Initially we thought that VPN should provide enough security to pass data through the internet, but now our Security team wants to encrypt the connection between SQL Servers also. Is it really needed or are we being paranoid and is that redundant?

Cheers

The point of the VPN is to secure the traffic so it can't be snooped on. As long as each server only allows connections from each other and they're locked down properly, there shouldn't be a problem. Also be sure that there's authentication in place for the database. If something gets through the firewall somehow and tries to connect, you don't want to just let them in.

However, if you don't trust the connection from your prod machine to the VPN, or the VPN to the SQL server, you might want to encrypt it (but at that point you might as well run the VPN on the client and on the SQL server). Don't forget that encrypting it twice will add overhead, and this probably isn't something you want, especially after having to communicate with a database that's off site.

This being said, you'll probably want to go with what the security team recommends. They may have other concerns and without talking to them, we won't know what those might be.


Phone number setup for security Several Q&As here highlight the danger of phone hacking. For example, this.

In a nutshell, the solution is to NOT give your phone number, except to your bank or government.

Unfortunately, that is a very impractical solution for a simple reason: phones have been created first to communicate with people. 2FA came as a second thought. In other words, I need to give a phone number to many different companies that will absolutely make sure NOT to follow best security practices (my plumber, the school for my kids, etc.)

So I was wondering, what are the solutions to keep the convenience of being able to communicate with many different people, but stay safe?

I have thought about the following solutions:

1) Get a burner phone, with a different phone number. Give that new phone number to my bank and government services. My "real phone" is considered unsafe.

Pros: seems safe
Cons: Impractical. The sim on the burner phone will deactivate after 3 months without usage. Do not want to carry 2 phone numbers, therefore will miss potentially important calls.

To solve the cons, I looked into solutions to transfer calls/SMS from one safe phone number to my main (unsafe) phone number:

2) Get an app like Viber (Google voice is not an option outside of the US) that gives you a different ("alias") phone number, and redirects it to my main phone number. Use the alias as my safe phone number (for banking).

Pros: convenient, only 1 phone, do not miss call/messages
Cons: seems unsafe, as if a hacker hacks my real (unsafe) phone number, he can still receive the SMS sent to the alias, and therefore gain access to my bank. Also, I need to trust the provider. In many cases, they seem to be smallish companies, so hard for me to trust.

3) Same setup, but my safe number is my real phone number. The alias is the unsafe one.

Pros: seems to be the safest (but please let me know if I miss something)
Cons: I need to change my phone number, so that's highly inconvenient (I've obviously already shared it with many people)

So my questions are the following:

Are there flaws in my reasoning above?
Are there other (ideally better) solutions that I am missing?

sadly, there is no way to guarantee your phone not being hacked.
I do recommend your last option on the issue of safety using the alias number as the unsafe. That does provide an extra layer of software to get down to your actual phone number.
But, for us to use the dang item, we must therefore open up at least one possible way for it to get broken into.
If we were to make an unhackable computer, it would have to never be on. Unhackable phone number, never use it. etc.


Encrypting individual files on OS X I am about to go paperless, and I want to protect the documents that I scan. The use case is that I'll be scanning paper documents, encrypting each file, and storing them locally and on various backup destinations. I've been researching various ideas for how to protect those documents, but I need more guidance. Here are the details of the system I'm trying to implement:

Protection is at file level. If someone gets their hands on a file, I want them to be unable to use it.
Transmission safety is out-of-scope, and assumed to be handled by whatever system is transporting the file.
The files will be encrypted on a Mac.
Decryption should be as widely-available as possible. For example, if I want to view a file on my iPhone, I should be able to use an existing library to write an app to do so.

I've looked at using security and encryption libraries in OS X to make a lightweight tool for this. I'm a software engineer, so I'm perfectly comfortable with writing my own application, but I am new to security. I am not comfortable making the security decisions without consulting people who know more than I do.

I've considered AES, but then I read about padding and encryption modes, and I got lost in the details of which to choose.
I've considered GnuPG, but I don't like the idea of having to download a separate tool. Yes, it's open source, but if I can use functionality built into the OS, that would be preferred.

Is there a recommended approach for this?

You can use openssl like this:

openssl enc -e -aes-256-cbc -salt -a -in /file/to/encrypt -out /file/encrypted

Replace -e with -d to decrypt. It should work both on OS X and Linux, don't know on other systems however.
    man openssl to list the options and the available cipher.

Edit: looks like openssl applies few rounds of MD5 (not the best hashing algorithm) to the key derivation. This makes brute force attacks easier.

A better solution could be GnuPG (i know you asked for a preinstalled tool by the way):

To encrypt:

gpg -c -a --cipher-algo AES256 /file/to/encrypt

To decrypt:

gpg /file/to/decrypt


How do I share a password in a FIPS-compliant manner? This is a really basic question, but I'm a newbie in security.  What I'm wondering is: How do I share a password for an encrypted document in a FIPS 140-2 compliant manner?  That is, say I have a PDF, DocumentA, encrypted with AES-128 using a password. I want to share DocumentA with Bob, via e-mail.  I e-mail Bob DocumentA - now how do I give him the password?

This is a situation that would come up quite frequently, so calling to verbally give him the password each time would not be convenient.  Obviously including the password in the e-mail itself is a terrible idea and defeats the purpose of encryption.

I've read the FIPS documentation from NIST (here), and the associated annexes A-D (available at the same link) and haven't been able to find any information on this rather crucial part.

Can anyone point me to the documentation that states this?  Thanks so much.

You must NEVER send a password over e-mail, or similar way. You can solve that issue using Public key cryptography (or asymmetrical cryptography). I won't get into much detail about how it works but the basic idea is that everyone has a pair of keys, a public (which should be public) and a private one (which should be kept secret). The public key is used to encrypt messages and the private key to decrypt messages.

For example if Bob wants to send "info.pdf" to Alice, he will encrypt it with Alice's public key, which is known, and only Alice's private key can be used for the decryption (only Alice knows the private key). This of course is a very minimal example and public key cryptography is a huge topic, so you should definitely make your research on the subject.

Now there are many easy ways you can use to encrypt your e-mails, files etc... For example PGP is one of the most popular standards to use for email encryption that uses symmetric-key cryptography to encrypt the data and public-key cryptography to encrypt the key that was used to encrypt the data. Then the receiver uses his private key to decrypt the encrypted-key, and then uses the decrypted-key to decrypt the data. So PGP uses both symmetric-key cryptography and public-key cryptography.


Cracking double encrypted router password? I noticed in the html of my router this parameter:

form.addParameter('Password', base64encode(SHA256(Password.value)));

So when I type in the password passw I get this via sslstrip:

2018-09-25 21:13:31,605 POST Data (192.168.1.1):
Username=acc&Password=ZTQ1ZDkwOTU3ZWVjNzM4NzcyNmM2YTFiMTc0ZGE3YjU2NmEyNGZmNGNiMDYwZGNiY2RmZWJiOTMxYTkzZmZlMw%3D%3D

Is this hash easy to crack via bruteforce/dictionary? I am still a beginner, but that looks like double encryption to me.
Also, is there some faster way of getting this password than cracking it?

I URL decoded it, then decoded it from base64, then passed it to an online hash database.

The result was:

Hash                                                                Type    Result
e45d90957eec7387726c6a1b174da7b566a24ff4cb060dcbcdfebb931a93ffe3    sha256  passw

The fact that this is an un-salted hash makes it easy to look up. All the encoding is a convenience for the login service, not a security control.

With a salt, you cannot just look it up, so you would need to bruteforce. If you knew the salt, success depends on the password and the wordlist you use. There are methods to make the wordlist more efficient for bruteforcing, but it ultimately is a function of time.


Safe to store encrypted data with (password protected) pfx file I have created a self signed certificate using Powershell's New-SelfSignedCertificate, with the intention of encrypting and storing a username / password in public.

Specifically using -

New-SelfSignedCertificate -TextExtension @("2.5.29.37={text}1.3.6.1.4.1.311.80.1")
                          -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider"
                          -DnsName sign.example.com
                          -CertStoreLocation  "Cert:\CurrentUser\My"
                          -KeyExportPolicy ExportableEncrypted -KeyUsage DataEncipherment
                          -KeyUsageProperty All -KeyLength 2048

$key = New-Object byte[](32)
$rng = [System.Security.Cryptography.RNGCryptoServiceProvider]::Create()
$rng.GetBytes($key)
$SecureStringWithKey = $cred.Password | ConvertFrom-SecureString -Key $key

I am then creating an object with the key, username and password securestring  and encrypting it through

Protect-CmsMessage -Content $object -To $thumbprint

Presuming that I have used a complex password for the pfx file, is it safe to store the pfx file and the encrypted string together in a github repository (along with the script that untangles the whole thing) or should I be taking steps to keep the pfx file safe also?

Yes it is safe to store encrypted data encryption key (DEK) materials (your PFX file matches this description) alongside the encrypted data.  You should store the key encryption key (KEK) (the password for the PFX) in separate storage (or remember it if practical).


What if I want a certificate, but DON'T want my domain in a Certificate Transparency log? Say I want to get a certificate for my domain, and say that I don't want this to result in the name of my domain appearing in certificate transparency logs or similar locations.  (The domain is only for my personal use, and I neither need nor want to advertise it to the whole world.)

What are my options? Do most providers generally submit certificates to transparency logs?
Or do all domains that end up getting SSL/TLS certificates automatically end up on such logs?

I would use a self-signed certificate, but that won't work, because I need to use a third-party service and it needs to be able to authenticate my domain.

Ideally they would be cheap like Let's Encrypt, but I don't even know what my options are.

(Yes, I'm aware DNS logs exist regardless, and I know obscurity isn't security, etc. That's not the point of my question, so please refrain from offering advice on that...)

The best solution for a subdomain is a wildcard certificate:

To protect secretdomain.example.com, get a *.example.com certificate. But it's expensive. The wildcard could be submitted to ct logs, but it will not reveal the real domain name.

The two other solution are:

using a CA that don't sumbit certificates to ct logs, but anybody visiting your website could submit your certificate. (some bots crawl the web do to it)
using a CA that submit to ct logs with name redaction, but browsers do not yet understant it, it's at your own risk.

Another possibility is to transform secretdomain.com to notsecretdomain.com/secretdomain: with that you avoir ct logs, DNS logs, and even https leaks (when using https, the path is protected, but not the domain)


How to sandbox students' Python 3 code submissions for automatic assignment evaluation on Windows 10? I am the TA for a coding class in which students will have to write Python 3 scripts to solve programming problems. An assignment consists of several problems, and for each problem the student is supposed to write a python program that will read input from standard input and write the output to the standard output. And for each problem there will be hidden test cases that we will use to evaluate their codes and grade them accordingly. So the idea is to automatize this process as much as possible. The problem is how to implement the whole framework to run students' assignments without compromising the safety of the system the assignments will be running on, which will probably be my laptop (which has Windows 10). I need to set up some kind of sandbox for Python 3, establishing limits for execution time, memory usage, disallowing access to the file system, networking, limiting imports only to safe modules from Python's standard library, etc.

Conceptually speaking I would like some kind of sand-boxed service that can receive a python script + some tests cases, the service runs the python script against the test cases in a safe environment (detecting compilation errors, time limit exceeded errors, memory limit exceeded errors, attempts to use forbidden libraries, etc.) and reporting the results back. So from Windows I can simply write a simple script that iterates over all students submissions and uses this service as a black-box to evaluate them.

Is anything like that possible on Windows 10? If so, how? My educated guess is that something like Docker or a Virtual Machine might be useful, but to be honest I'm not really sure because I lack enough expertise in these technologies, so I'm open to any suggestions.

Any advises on how to set up a secure system for automatic evaluation of untrusted Python 3 code submissions will be very appreciated.

pysandbox is an implementation of a sandbox in Python. It is designed to execute untrusted Python code (in our case, code submitted by a user) within a constrained environment which can be configured by a pysandbox deployer.

Please refer to this link for more information:
https://www.software.ac.uk/blog/2017-11-23-executing-python-code-submitted-web-service


Why is the 2nd step in two-step authentication not a single click? The case

I'm using Google 2-Step Verification.

The question

Why does Google use a code as second step? Why not just an android app where you can click "It's me"?

If two or more people try accessing the same account at the same time, and only one of those users is legitimate, it wouldn't be possible for the app to know which sign in attempt it should verify, without the user identifying their particular attempt in some way.

As such it makes sense for the user to apply a code directly to their session. Also notable is that the codes are generated offline, based on a secret and device time. Using an "It's me" button would require an intermediary server through which the web app and the mobile app confirm the authentication request. This adds expense to the app, and introduces dependencies, a point of failure and potential point of vulnerability.

  @Scott if someone is able to fake a "it's me" notification, that means he have stolen the original secret. He might as well still the your MFA code

Imagine you are signing into your Google account, and a hacker is also attempting to sign in to your Google account. Both of you are at the MFA stage. Only you have the MFA device.

You press your "It's me" button to authenticate ... Which of the 2 pending sessions does that authenticate? The "It's me" idea then only works if you select the correct session. In which case a code is simpler and safer.

  In any case, the "that's me" notification can be a response to a challenge sent by the authentication server on your session. In which case you will be notified if an attacker attempted to log in. Any idea why that wouldn't work?

I can see what you are getting at with the device being notified of the attempt, and then you just confirm it with the app. It's not an unfeasible design. I guess ultimately it comes down to pros and cons:

Your suggested method:

Intermediate server(s) required. To send notifications, to authenticate devices and session
Servers require maintenance, cost money to run, can themselves be hacked, can fail / or be unreachable.
The web app requires to talk to the MFA verification server.
Only works online.
Potentially more security holes and complexity.

The current code method:

Free
Works offline
No servers required
Open standard


Any way to browse OSVDB? I've been playing with nikto and I see some vulnerabilities listed in the scan for my dev server. For example, I see osvdb-XXXX, with a short description after it. I am googling this string, osvdb-XXXX and I am getting very little useful information back. Even when I go straight to osvdb.org I am absolutely perplexed that a browseable database does not exist here.

Some of the short descriptions next to the vulnerabilities detected by the scan are helpful, while others are cryptic. How can I research what vulnerability is being found by nikto?

Edit

I took the liberty of emailing the address I found on the osvdb blog site. They responded simply with The database is currently not available. So I'll amend my question to say is there anywhere other than the osvdb site where I can find information about what nikto is telling me?

Further response from open security foundation

There is a blog post coming with more detail, but do not plan to see it
return. @osvdb on Twitter for announcements.

As of today (April 5th, 2016) The project was shut down due to lack of contribution, and there is no plan for it to return.

  As of today, a decision has been made to shut down the Open Sourced Vulnerability Database (OSVDB), and will not return. We are not looking for anyone to offer assistance at this point, and it will not be resurrected in its previous form.


Security benefit of hardware backed host keys for OpenSSH There was recently a "two for the price of one" deal on the Yubikey 4 and now I have too many of them.

This got me thinking about things to do with them, more or less useful. Of course I already use the smart card features to secure my SSH CA and my personal SSH keys. But could it also be used to secure host keys?

This would most certainly require the use of an ssh-agent since it seems exceedingly impractical to enter the PIN code every time a client connects to the server. After a quick look in the sshd_config manual it is actually possible to point it to a SSH_AUTH_SOCK instead of files on disk for host keys using HostKeyAgent.

Could you elaborate your thoughts about the actual security gain in a setup like this? For me the most obvious is a physical key, you can always be sure that the key is not copied somewhere, and if the yubikey is gone you can easily notice this.

AFAIK, your assessment is quite correct. Your physical device migrates the risk for your key to be stolen from the virtual to the physical world. So if your server is temporarily compromised you have a minimal risk that your key has been stolen. Which a huge difference!

However, it does not generally prevent the abuse of your key. So if someone hacks your server, he can sign arbitrary things with your key, just like your SSH host would do. This includes chosen plain text attacks, which enable the attacker to guess your key in less time. Therefore, it would not efficiently protect a permanently compromised system.


Why hasn't anyone attempted to fix ARP (ARP Spoofing/Poisoning)? I've tried researching this question, but can't find any relevant information. The protocol was standardized in 1982, but as far as I know, there have been no attempts to try and fix it.

My guess would be that "fixing" the protocol would cause more problems than it would solve. Maybe I don't know enough and the answer to why it hasn't been fixed is too technical. Granted major code bases would have to be updated/changed, why not just create a newer, safer protocol?

My guess would be that "fixing" the protocol would cause more problems than it would solve.

Partly answers the question indeed.

IPv4

ARP was more a solution to a problem that occurred when we started using internal networks. One might even call it a hack to get things working internally, and the entire idea to communicate via hardware addresses without the need for an internet protocol let to the development of the ARP protocol. At the time, only few were concerned with security, let alone network security. Like many protocols and systems developed in the early '80 (STMP, FTP, ...), people were happy if it worked at all, not thinking this could lead to major security-related problems in the next decades. Since then we've tried to replace old systems and protocols, but is has proven hard, mostly due to compatibility and legacy issues. All of the OSI-7 layer protocols can make use of TLS tunnels to secure communication and guarantee confidentiality. Since ARP is so basic, and widely used replacing it wit a secure alternative will be very difficult.

IPv6

Since the '90 we know security must be taken into account when drafting new protocols. IPv6 is the living prove, and can be configured to work with IPSec to tunnel traffic in the network layer, and other nifty features. One of these features is NDP, which basically does the same thing as ARP, but different. NDP learned its lesson from the ARP ages, and does offer additional security via SEND (Secure Neighbor Discovery Protocol). SEND uses crypto based on addresses (this is quite awesome) to determine the authenticity of a claim. Sadly IPv6 still isn't de facto today, for the same reasons as ARP is still alive and kicking.


Open wireless network and OpenWRT isolation function - any risk? What security risks would be caused by using a wireless router with no encryption for the wifi and by configuring it with:

vi /etc/config/wireless
option isolate 1

"HW" isolation. Running OpenWRT. In this way, the wireless clients would be separated and wouldn't be able to capture each others traffic. Or are there still security problems, because a wireless client would still be able to say: "I am 192.168.1.1, route the traffic through me" - even when using "option isolate 1"?

In term of risk, enabling isolation can only be an improvement if you start with an open router without any kind of protection.

Isolation should protect you from DNS poisoning (like the example you wrote) but also from ARP poisoning (see: http://arxiv.org/abs/1404.2172).


What information will dig leak to an attacker? What information will the axfr and ixfr commands in DIG provide to an attacker?

AXFR is the traditional way of zone transferring - you just completely copy the dns records from one zone to the other - an attacker will have a complete list of resources in the organizations and if you save some more information on those servers on your nameserver it will be included

IXFR on the other hand helps sysadmins in replicating an already given zone that was doing a complete AXFR in the past and need to be updated to the latest record revision on the nameserver, without the hassle and band-choking of a complete copy of records.
in IXFR you can select the revision that you have and the server will provide you with the updated data since your revision, to an attacker is the same as before - just less information.


Time needed to generate an RSA signature of a document How does the length of the RSA key and the size of the document affect the time it takes to sign a document using SHA-1 and RSA?

I used CrypTool to check it, but the time does not appear to be larger for big documents. I don't know whether it is problem with CrypTool or the way I used it (maybe I used too small documents).

Generally, with a digital signature for an asymmetric key (such as RSA) - the signature is created over the hash (SHA-1).  The hash creates a fixed size data block (SHA-1 - 160 bits) which is the input to the asymmetric encryption function.

Hash functions - by and large - are created to execute quite quickly. By quickly, it's generally linearly proportional to the size of the input.  Chances are fairly good that on an average computer, with a decently written API for your hash function, you will have trouble seeing a big difference without a dramatic change in file size.  Hash functions are built for efficiency, and hash library makers do a decent job of keeping these optimized for the operating system and CPU.  My suspicision (with the test set sizes unknown) is that you have a calibration problem - CrypTool is unlikely to be able to measure the variations in time to proccess the input because the delta between "fast" and "slow" is too minor to be measurable.

Your RSA key pair size WILL NOT change - to change the size of your key pair, you have to generate a new key and identify that new key pair as the input to the signature.  Here's a nice paper on how bigger RSA key sizes will impact signature generation and verification.

No matter what the size of your RSA signature key is, the input length of the data will be 160b due to the fact that you are using SHA-1 to hash the data before sending it for signature.  So once a key pair is determined, if you are measuring only the execution of the RSA algorithn, you won't see any difference in processing time (unless it's also affected by other operations occuring on your system) due to differences in the input data to be signed.


How to block a cloned SIM card? If someone manages to get access to my iPhone's SIM card (I left the phone at a repair shop for a few days and forgot to take the SIM card out).

Now, the repair people at that shop were acting all shifty when I picked up the phone and quoted really outrageous prices for parts replacement for it to be fixed (including the motherboard). So I didn't have them do any work on it.

I was just wondering if they cloned my SIM card or something, because now that I got a new phone on the same line (same number) I'm getting occassional calls from some foreign number with a foreign country code.

Will getting a new / replacement SIM card for the same number cancel out their cloned card (if it was indeed cloned? and block them forever?

A mobile phone, generally speaking (*), is broadcasting the message "the SIM card I have with the ID XXXX is now available on the network". This ID is called IMEI IMSI (**) and is unique to a SIM card.

The IMSI is then mapped to a phone number by your provider.

If you break this chain (by going to the network provider and requesting a new SIM card) the cloned card is useless: its IMSI stops to be associated with your phone number (which you may still keep on the new SIM card).

The technical corner: cloning a card into a functioning one is not a simple task (particularly if the card is protected by a PIN). It requires rogue cooperation with the network operator but once such a card is available, it is placed in a SIM-dialer - a device which continuously dials premium (expensive) numbers so that you run out of credit. This is why it is important to have it blocked as soon as possible, especially when you are in a foreign country. Fun fact: this SIM dialer is called in French a "pondeuse", which refers to a hen laying eggs.

That was for the "someone could call on my behalf" part.

You also mention that you are now getting calls from unknown numbers. These calls are not a danger, they are just particularly annoying. You can try to add them to your automatic rejection list and if they persist, then the only way is to change your number (which can be done without changing the SIM card, per above).

The shop may have given your number to scammers, you will never know. Or it may just be a coincidence.

As a side note, beware of calls which just ring once or twice, trying to get you to call back (or if you pick the phone up, there is a generic message like "I cannot hear you, hello? hello? Please call back this is important"). There are usually two categories of such scam calls:

the ones which show a local number. If you call that number you get a message of the type "you have received a voice mail, please dial  to retrieve it"
the ones which show a premium number with the international prefix for your country. The idea is that when you live for instance in France (prefix +33) you may be less reluctant to call back +33899235467 than an well-advertised 0 899 ... which is more recognizable as an expensive (premium) number.

(*) "generally speaking" means that what follows is mostly correct, there are many simplifications and some inaccuracies but you should get the whole picture.

(**) I initially wrote by mistake "IMEI" instead of IMSI. The IMEI is another identifier, unique unique to the phone itself (not the SIM). Its uniqueness is supposed to help to blacklist a stolen phone but it usually does not work (either the blacklisting is not applied by the carrier, or is reset by the thieves to something else).


What are realistic rates for brute force hashing? I'm trying to gauge password strength assuming that the attacker has a hash of my password. Can anyone cite some realistic contemporary rates at which someone could perform various hashes? I know most sites use unnecessarily weak hashes like MD5 of SHA-1, so rates for these would be the most relevant.

For a simple invocation of MD5 or SHA-1, a realistic rate is between 1 and 10 billions of passwords per second. That's what can be achieved with a good GPU. Furthermore, if the hashing is not salted, then the attacker can share the effort between several attack sessions, usually using precomputed tables (e.g. rainbow tables): an attacker, somewhere, had to hash gazillions of possible passwords once, but then the resulting tables can be applied to thousands of hashes with only a small cost.

If the hash function is proper (as described in this answer), then it uses a slowdown parameter which makes the function as slow as can be wished for. Slowness impacts both the defender (the honest server who uses the hash to authenticate users) and the attacker. We could imagine, for instance, that the defender is ready to invest 10ms worth of his own CPU on each hashing instance, which means that the defender can handle 100 password hashes per second. The attacker can throw more PC at the issue, with multiple cores, and possibly use specialized hardware (GPU, FPGA...), which may give him some boost; let's say that the attacker can be 100 times more efficient at the password hashing than the defender, leading to brute force performance of 10000 guesses per second.

The boost that the attacker can obtain through specialized hardware depends on the function (e.g. a GPU will be good for attacking PBKD2/SHA-256, not as much for attacking bcrypt). How much hardware the attacker will be able to throw at the problem also depends on external parameters (his budget, his motivation...). The slowness used by the defender is a trade-off, because increased slowness uses server resources and may make it more vulnerable to denial-of-service attacks.


Is showing CAPTCHA after n failed attempts less secure? My boss asked me how I would improve the login strategy they have implemented at the moment: introduce user, password and resolve a .NET captcha from the first attempt.

An auditor security team said that our web applications may be vulnerable to brute force attacks, so I propose them to carry out the following strategy:

Let the users introduce incorrectly user and password 3 times.
After the third failed attempt, the captcha must be also resolved.
After another 3 failed attemps, the user will be temporaly locked out at IP level (a few minutes).

I proposed that because it will also improve a little bit the usability. A big part of our users are elderly people, and it is annoying for them to resolve the captcha every time they want to log in.

So, my question is: will it be safer to show the captcha from the beginning? Some time ago, a lot of websites used to show it after n failed attemps, but now they prefer to make sure the user is not a robot every time he wants to be authenticated. Is there any reason to really do that?

If brute forcing is your main worry you can just have it show up after 5 attempts or maybe even 10. If someone tried 5 variations of their password it sounds pretty reasonable to have a captcha pull up, even with elderly users.

When you are talking about brute forcing we could be talking about hundreds of attempts within a few seconds, so that would still help with mitigating that.


Does it pose a problem to use 'strict-dynamic' with a hash and not a nonce? Ever since CSP 3 introduced strict-dynamic, Google has recommended its usage. Indeed, the idea of maintaining one "root" script, which in turn loads all other necessary scripts, sets up event handlers, etc. instead of maintaining a whitelist of allowed domains or hashes for every inline script seems positive.

However, whenever I read about strict-dynamic, I always read about the inclusion of a nonce. This can prove to be difficult, if for instance the page is generated by an application server, yet the header is added via a reverse proxy later down the line.

In order to mitigate this, I tried to use the other mechanism to identify scripts: hashes. More specifically, the 'sha256-...' keyword.

The complete Conent Security Policy would look like this then:

script-src 'strict-dynamic' 'sha256-XBQNNdy0amIuLO3171zDY4zf/RwRjJMx+MhGafC3R4M=' 'unsafe-inline' http: https:;
object-src 'none';
base-uri 'none';
report-uri https://csp.example.com;

Is there any reason why this might be less safe than a nonce-based approach?

Your policy is perfectly fine (you can paste it into the CSP Evaluator to confirm) -- hashes are a good alternative to nonces, particularly in static applications.

There are two reasons why most of the advice about policies with strict-dynamic focus on nonces rather than hashes:

Applications often dynamically interpolate values inside <script> blocks (e.g. a JS object with some user-controlled data, a string with the user's email, etc.). In these cases you cannot use hashes because you don't know what the contents of the script are ahead of time, whereas a nonce will bless the script regardless of its contents.
External scripts (<script src="...">) must be blessed by nonces because hashes apply only to inline script blocks. So if your site has external scripts it would have to use an inline bootstrapping script blessed by a hash, which would then load any external JS. This requires some refactoring and can affect the performance of the page because external scripts will only start to load once the bootstrap script executes.

But if your application doesn't have these problems, then a hash-based policy is a good approach.


Can Facebook login to my app? This sounds maybe like a stupid question, but I'm wondering myself if this is theoretically possible.

Let's say I'm using Facebook login in my app. If the login is successful I get I get back an OAuth token from Facebook to make API requests. Now Facebook has also this token and could use this to log in to my app and fetch all the data inside this app. I'm not sure if this is possible, but this could be a security concern.

Many thanks!

To specifically address the scenario, Facebook doesn't need to wait until a user logs in to capture an OAuth token.  Since you're trusting Facebook as your authentication provider, they can generate a valid OAuth token for any user in their system anytime they please.

Given that, there are three potentially correct answers here.

This is not a threat, because it's outside of your threat model, or an negligible risk.  In most cases this is going to be the correct answer.  It's outside of your threat model, because you're assuming that Facebook is correctly authenticating people and if you get an OAuth token from them, it's for the authenticated user they say it's for.  It's a negligible risk because it's unlikely Facebook cares about your application data, and it's unlikely that even if they do, they're willing to abuse a system they've spent a large amount of money to build and operate, and that is popular only because it's trusted.  That would defeat their larger and more valuable goal of getting their fingers in every corner of the web.
It is a threat, and can be mitigated with a second authentication factor.  If this is a serious enough risk to your application for whatever reason, you can mitigate it for existing users of your app by requiring a second authentication factor that Facebook doesn't have control over, so that you're not relying solely on the OAuth token.
If it is a serious threat, don't use Facebook OAuth at all.  If you really don't trust them, then don't use their system.  Simple as that.  If the data in your application is so sensitive that it warrants requiring uses to create a new set of credentials, make them do that.

All of that said, the vast, vast majority of cases are going to fall under scenario 1.  First, when you choose to use Facebook OAuth, you're doing it so that you don't need to worry about authentication, and threats to authentication (for the most part) become external.  Additionally, the thought that Facebook would abuse the system to harm you or your users is more of a fictional plot than a real threat, and the actually likelihood of that occurring is generally negligible, and not worth the cost, effort, and complexity of mitigating.


Are there any examples of when personal email data can be brought into a lawsuit involving a corporation? If users bring their own device (BYOD) and they have corporate Exchange (or Goodlink email) on that device, could the other email accounts on that device be open to a legal search?

Would the SMS messages (WhatsApp, or other) be open to a legal search?
If the answer is yes, both accounts could be searched, what if the person used two different devices for work and personal (or business1 and business2 for that matter)?  Could both physical devices be searched?
Are there any corporate policies that could limit the search to just corporate data, and protect the investigation of our user's personal lives in a BYOD scenario?

I'm mostly interested in anything that applies to the US or UK

In the United States, generally anyone can subpoena anyone or anything as part of the "discovery" process.  It is up to the presiding Judge to decide whether or not this is relevant or allowable.

In a civil action, as opposed to a criminal one; some typical protections (e.g. 5th amendment protection against self-incrimination) do not apply.  Thus, it is far easier to compel disclosure of information during a civil case than during a criminal one in the United States.

So to answer your question's points:

1) Yes, they would be open to a subpoena; this is distinct from a "legal search" conducted by law enforcement personnel.  The party receiving a subpoena would be compelled to hand over the information in an unedited/original form.  In a criminal case however, yes, law enforcement would be able to subpoena the provider or the individual to obtain this information for investigation, or just seize it themselves.

2) Yes, the information on these devices could be subpoenaed if it is relevant to the case or controversy at hand.  The court could order the devices analyzed by a forensic analyst, or simply they be turned over, etc.

3) Corporate policies do not trump the sovereignty of the state.  As Max Weber famously stated, "The state is the entity with the monopoly on the legitimate use of force."  Since force majeure, in the form of a subpoena carrying with it threat of criminal charges like contempt of court, trumps any corporate policy -- no policy could prevent a court from ordering disclosure of your information as long as it resides within the court's jursidiction.  If data relevant to a court case is subpoenaed, and the court grants such a request, no corporate policy can defend you.

I am not an attorney and you should consult a knowledgeable attorney on these matters when devising corporate policies and strategies for BYOD and measures to mitigate risks of discovery actions.


How to generate ffdhe from rfc7919 Everyone recommends to use the pre-defined ffdhe groups from https://tools.ietf.org/html/rfc7919
There are multiple sources (for example mozilla) where I can download the DH PARAMETERS file but how can I generate it with the information provided in https://tools.ietf.org/html/rfc7919#appendix-A.3?


Someone got my ip with grabify, what should I do? So right after I clicked the link, the owner of the link sent a screenshot, and it was accurate, the city was correct, so not long after my internet box reseted out of nowhere, while I was in class, it would log me off the meeting and say that someone else was trying to log somewhere else, which is so weird. And usually what ive read said that they just can check my online activity, so if I buy something off the internet, would that tell them my adress?

The attacker is trying to trick you into thinking you're compromised, but you're not.
Your IP address is not "private" information. In fact, you announce your IP address to every client you ever connect to, such as any web server of any website you visit, or any other player in an online game you're playing. Just to illustrate my point, in order to visit stackexchange.com, any packet I send is seen by six different hosts - all of which now know my IP address.
Grabify allows users to see from which IP addresses the link was clicked on, and attackers like to use this information to intimidate people. Notice that I say "attackers", not "hackers" - there is no hacking involved. They are trying to intimidate you, claiming that they have attacked you, or that they are going to attack you - and I'm very certain they're going to demand money to "stop the attack" - even though there never was any attack to begin with.

What information does an IP address contain?

Who your ISP is. That's about it. From that, your rough location can be determined, but that depends entirely on how your ISP operates and allocates numbers. For example, I am a customer of a local ISP that only serves customers in my city and the nearby area. As such, if you look at my IP address, you can tell which city I live in. If I were to be subscribed to an ISP that serves the whole country and the ISP would not differentiate at all in terms of network allocation, then the closest you would get is my country.
The attacker definitely does not know your actual, physical location or home address - at least not from your IP alone.

Then how come all these other things happened?

Pattern recognition. It's similar to how horoscopes work. Your horoscope may tell you that you will have a good impact on people, and wanting to believe in the horoscope, every little positive interaction with another person now becomes "evidence" of the horoscope being correct.
Likewise, your modem resetting "out of nowhere" is a thing that happens regularly and has countless normal explanations, such as your ISP restarting a server for maintenance purposes. If that had happened to you before the whole incident, you would not have considered it "weird" or to be some sort of indicator for an attack.

What should you do now?

Nothing. Stop communication with the attacker and just carry on. Any threats they make are just as credible as an email from metropolitan.ploice@hotmail.com telling you that you have to send them 200 USD worth of Steam Gift Cards or you will be arrested.


What kind of attack is prevented by Apache2's error code AH02032 ("Hostname provided via SNI and hostname provided via HTTP are different")? I saw in my Apache2 server logs messages like

 [ssl:error] [pid 28482] AH02032: Hostname xxx.yyy.zzz.www:443 provided via SNI and hostname xxx.yyy.zzz.www provided via HTTP are different

One of these error message was triggered by a request from researchscan367.eecs.umich.edu, so I presume they are scanning for some known vulnerability. What kind of vulnerability or attack vector is prevented by the error?

Server Name Indication (SNI) is a TLS extension which allows a TLS client to indicate which host it is trying to reach. This is important for web servers with virtual hosts (i.e. multiple domains hosted from one box) so that they can decide which certificate to return. Normally the target virtual host is detected via the Host HTTP header, but that can't be sent before a TLS tunnel is constructed. SNI allows the TLS client to indicate the name so that the correct certificate can be served, before the underlying HTTP call is made. Another feature of most TLS servers is that SNI can be used to pick between different TLS configurations that have been configured for each virtual host.

Since you now have two indicators of which host you were trying to reach (SNI and Host header) there may be odd behaviours if you force them not to match. Now, imagine a situation where you've got a site which uses HTTPS, but also an administrative subdomain, and they're both hosted on the same server. The administrative subdomain is locked down at the SNI configuration level so that it requires a client certificate. This means that regular site usage just runs normal HTTPS, but you need a client certificate to connect to the admin subdomain.

However, if you were to make a request where the SNI points to the main domain, but the Host header points to the administrative subdomain, you can construct the TLS tunnel without the client certificate (because the main site's rules are used) but the web server may serve content as if you were connecting to the administrative subdomain. This could allow you to bypass that client certificate restriction.


Security controls around data in motion? I am an Information Security Analyst, trying to understand the difference between data in transit and data in motion. I found the listed below definitions:

Data In Transit is defined as data moving outside of the server such as between client and server, server to server, web app server to DB server and vice/versa.

Data In Motion is defined as being in preparation of transmission, moving around or place to place on or within the server itself but not transiting off of the server, or sometimes between servers when the connection between servers is a direct private connection such as data moving from server to SAN/NAS, not over a traditional LAN.

Reference - http://commonsensesecurity.net/difference-data-transit-data-motion

What security controls need to be in place to protect data in motion which are different than data in transit?

Memory protection schemes(DEP,ASLR,etc), I/O protections(e.g. guards against write-corruption), buffer/cache clearing, etc are a couple examples of controls to protect data in motion.

Basically: any controls that are concerned with maintaining data integrity and security while it is resident within a computer system but not at rest, rather than while it is transiting between systems, is a control for data in motion.

Think of defending against Spectre versus defending against a network MitM attack.

To address the observations in the linked article; yes, data in motion controls are not usually concerned with cryptographic protections.

As an example data flow:

[data on disk](at rest) >>
[program reads](now in 'motion') >>
[prepares to send over network](still in motion) >>
[sent data now "on the wire"](in transit) >>
[received by other system](now in motion again) >>
[writing to disk](still in motion) >>
[written to disk successfully](now at rest)


Identify an unknown type of hash I've come across an unknown type of hash value which looks like this:

AAAAAATOM2KIII+kbR/Dqw3TLTw4PHsGPZft2c+b93rImFIuAQ==

The corresponding hex string is:

0000000004CE336288208FA46D1FC3AB0DD32D3C383C7B063D97EDD9CF9BF77AC898522E01

I've tried to identify this string in OnlineHashCrack but it seems I cannot get any hint. Can someone help me identify this hash type?

Some more examples:

Hash: AAAAAASaQwt3IaNVmGiQJxXHm1ZT888dHmAnmYOksBLkChGUYA==

Hex: 00000000049A430B7721A3559868902715C79B5653F3CF1D1E60279983A4B012E40A119460

Hash: AAAAAASeclRQJiE6vfoIjp8HxTZRaqMxMGMORZqrdSmOAUuFfA==

Hex: 00000000049E72545026213ABDFA088E9F07C536516AA33130630E459AAB75298E014B857C

More:

AAAAAAQh51mzdpW5w+/+yK46nezAbMp5xn3XGMRxNBu7wTSWHQ==
AAAAAAT8KI/Xub72swAm0CPT/1DoS9jig4IyfK6ZnvU+8VGaXg==
AAAAAATYILi+qpLlRt3UACCDwHM5y3kvZhma+za0VmYDjkyRTQ==
AAAAAAQLXlq1CHz1kLFiJ2LKER3y/D2E6ktH8tUva6XzmLfonQ==

This is not a hash. You always have a base64 encoded data (the one that ends with '==') and the hex value of the decoded data.

I am not sure what type of data this is, but I am almost sure that it is binary data.

AAAAAATOM2KIII+kbR/Dqw3TLTw4PHsGPZft2c+b93rImFIuAQ==
    0000000004CE336288208FA46D1FC3AB0DD32D3C383C7B063D97EDD9CF9BF77AC898522E01
AAAAAASaQwt3IaNVmGiQJxXHm1ZT888dHmAnmYOksBLkChGUYA==
    00000000049A430B7721A3559868902715C79B5653F3CF1D1E60279983A4B012E40A119460
AAAAAASeclRQJiE6vfoIjp8HxTZRaqMxMGMORZqrdSmOAUuFfA==
    00000000049E72545026213ABDFA088E9F07C536516AA33130630E459AAB75298E014B857C
AAAAAAQh51mzdpW5w+/+yK46nezAbMp5xn3XGMRxNBu7wTSWHQ==
    000000000421E759B37695B9C3EFFEC8AE3A9DECC06CCA79C67DD718C471341BBBC134961D
AAAAAAT8KI/Xub72swAm0CPT/1DoS9jig4IyfK6ZnvU+8VGaXg==
    0000000004FC288FD7B9BEF6B30026D023D3FF50E84BD8E28382327CAE999EF53EF1519A5E
AAAAAATYILi+qpLlRt3UACCDwHM5y3kvZhma+za0VmYDjkyRTQ==
    0000000004D820B8BEAA92E546DDD4002083C07339CB792F66199AFB36B45666038E4C914D
AAAAAAQLXlq1CHz1kLFiJ2LKER3y/D2E6ktH8tUva6XzmLfonQ==
    00000000040B5E5AB5087CF590B1622762CA111DF2FC3D84EA4B47F2D52F6BA5F398B7E89D