Can websites detect if visitors are logged in to mainstream ID providers and collect their IDs? Logging in to websites using mainstream IDs (Google/Facebook/Github etc.) by means of OAuth (or similar) has nowadays become a feature that people expect.

Not that long ago the corresponding user experience included popups asking if the website should be allowed access the user's data from the ID provider. But today even that is no longer a norm: you can login with just a single click (for example, logging in to travis-ci.com with GitHub account).

Setting aside legal limitations (GDPR etc.), is it technically possible for websites to silently attempt to log visitors in with a range of ID providers in order to figure out who is visiting and grab whatever data is grabbable from those providers?

In other words, when I browse websites while logged in to say Facebook, are they technically able to log me in behind the scenes and see my name and whatever Facebook lets them see?

It depends.

  Can websites see if you are logged into?

Yes, if you have third-party cookies enabled.

  Are they able to log you in behind your back?

This shouldn't be possible.

  Can they grab data from a website site?

I'm not to sure on this one but this should depend on the security of the website. Maybe you could do some mischief but properly set up x-frame-options
in combination with a secure CORS implementation should prevent most of it.

Please note I only mention CORS because it plays a role in the practical implementation of such systems and has no direct security benefits.


Is it safe to send the user's encrypted password back to them in the browser? Why? I have planned to send the encrypted password from the application back to the user. I am currently using AES to encrypt user passwords.

I want to send the user's encrypted password back to them in the browser to help them with automatic logging in after a forgot password action.

Is it safe to do this?

Short answer: This is extremely dangerous and must be avoided.

There are a few things here that should be changed. First, user passwords must always be hashed. As I said in the comments, bcrypt is a common and appropriate hashing mechanism.

Secondly, sending credentials back to a user leaves it open for abuse by an attacker - there is never a good reason to send this information back to the user. When a user exercises the forgot password functionality of an application, they should log back in with the new password. This removes your feature of logging the user in with their own encrypted password automatically.


How can SSL improve page load times? I just came across this statement on the CloudFlare SSL page: "Modern SSL can actually improve page load times."

How can SSL improve page load times? Is there a situation where loading an HTTPS page could be faster than loading an HTTP-only page?

I don't believe TLS can actually improve page load times on its own. What they are claiming is that their service is optimized so that performance-improving features (in particular HTTP/2) are not incompatible with encryption, and that a website served over HTTPS (likely using HTTP/2, session resumption, etc) on Cloudflare will be faster than a website served over HTTP without their services. This is supported by their general statements on performance:

  HTTPS isn’t what it used to be. It’s faster, more secure, and used by more websites than ever before. SSL enables HTTP/2, which has the potential to make websites up to two times faster with no changes to existing codebases. Modern TLS also includes performance-oriented features like session resumption, OCSP stapling, and elliptic curve cryptography that uses smaller keys (resulting in a faster handshake). TLS 1.3 reduces latency even further and removes insecure features of TLS making HTTPS more secure and performant than any previous version of TLS and its non-secure counterpart, HTTP.

So while TLS on its own cannot improve performance (it necessarily adds a small amount of computational overhead), some modern network protocols like HTTP/2 only work over TLS. While this isn't standardized, practically all browsers require TLS with it. As such, you could argue that TLS is necessary to use protocols that improve performance, but TLS alone speeds nothing up.


Authentication providers for applications with no internet connection I have an interesting use case where users need to authenticate to applications running in environments that might not have internet access or even access to an authentication server. Administrators need to be able to grant and revoke access to individual users without direct access to the application. The admins would rather not maintain and operate the solution though. Does any authentication provider or service exist that can do the trick?

I have already explored OCRA services such as Protectimus and Gemalto, and also RSA SecurID, but to verify challenge responses they all seem to require that the application call their servers.

Another possibility is to use an OpenConnect ID provider such that a user logs in via her mobile device, get an id token, and copy it into the application. However, the application still needs to have up-to-date signing keys or the client secret. More critically though, the user might not have a practical way to copy the token into the app in practice, as the token can be long.

More Info

If it helps clarify the reason for these requirements:

The users are support personnel from my company.
The application runs in its own VM in another company's internal network.
At this time, the app and VM are "closed". Only my company's support team are allowed to log in to its support account -- not the customer.

All security solutions will need to call a service of some kind since you need separation between the application and the security provider.

However, that doesn't mean they have to be on different physical servers and certainly not that they have to be on the Internet. If you have no network at all, your users won't be able to access the server so I'm assuming you have a local network with no Internet.

With only a single server, your options are limited and security will be limited too. The best option in this case will be a hardware security store. The security is offloaded to the hardware which ideally both stores keys and does the authentication processing.

Otherwise, local key servers will provide some measure of security but, of course, when active, they are susceptible to memory attacks.

Moving to multiple physical or logical servers is better, especially if the security server is isolated on it's own secure network since that reduces the attack surface.

All depends on the value of your data and the risk appetite you have.


Intrusion detection architecture I want to propose an architecture of intrusion detection on the schema shown below. Should I place one IDS in front of each server, or would one be sufficient for all the servers?

The main information I get from your question is that you don't know what kind of threats to expect in your network, but nevertheless you hope to address them using some kind of IDS. This will probably fail.

So the first thing would be to make a risk analysis, develop a threat model and then do a cost/benefit analysis to decide which threats should addressed and with which risks you can live. And because the threat landscape is moving you should reevaluate your decisions often enough.

Just an example: If you fear an attacker coming from the outside you could deploy a passive central IDS to detect intrusions. Unfortunately this will not prevent intrusions so they will probably spread through your network and can only be detected with IDS which near the host. Host-based IDS itself might also work unless the attacker is able to disable them once they owned the system. Instead of using passive IDS you might use active components which not only try to detect but also to prevent attacks. You find them usually named as firewalls,IPS, NGFW, UTM, Secure Gateway... . But be aware that none of these will detect and prevent everything, and usually they detect much less than their marketing claims.

And of course you should now on which level you expect the attacks: a simple packet filter will not detect application level attacks and how good something like drive-by-downloads or waterholing attacks with 0-day exploits get detected depends a lot on the capabilities of the IDS/IPS and also a lot on your ability to tune it specific to your environment.

So just don't expect just to put something there and be safe - you probably have to invest lots of money into technologies, but also a lot of knowledge and man-power to maintain the system and keep up with the latest threats.

In summary: there is no clear answer to your problem. Only after you have made an in-depth risk analysis you can decide what the best way would be with the amount of money, man-power and knowledge in your budget.


Reverse Engineering Unable to identify String encryption I'm on an ethical hacking challenge. Which I asked here before. But I need a hint on solving this puzzle.

Note: I do not need the problem resolved, just a hint.

URI=3b6e6e3b6675707d7b7c7175703b767875777f3b676075663a7c607978

When converting this from HEX editor values it returns me this.

;nn;fup}{|qup;vxuw;g`uf:|`yx

So I tried somthing like letter combination. But nothing. And rearranging like this:

URI = ;nn;fup;www;numberValuesOfEach;.com:SomePort

based on their values.  And

HOST=14160116180503165914181a591505

HEX leaves me to this:

....Y...Y...

As requested, here is a hint:

Both the URI and host are encoded in hexadecimal, with each character XORed against the same value. (That is, it's a simple "XOR cipher".)

The URI ends with the letters html.

I'll let you figure out the host yourself. Trial and error is a valid method.


Forensics after web server compromise I was using sftp to give access to clients to certain folders so that they could modify their apache virtual hosts as desired. Until someone uploaded a php backdoor and erased all virtual hosts :).

I was wondering if there is a way I can get the ip of the attacker ?

I guess I will see nothing in access.log because most common php backdoors use the system function to execute commands in shell.

The most important thing to realize is that your server is compromised through and through. While the attacker may not have installed any rootkits or the like, you have no way of knowing. Your only options is to take the system offline and analyze it using an external source. The sooner the better, as otherwise you'll be trampling over any evidence yourself through normal use of the server.

So, essentially, take the server offline, take out the disk, clone it, wipe it down, use backups (if you have them!) to get a usable state back, then start to look at the data on the disk (remember to just examine the data - do not ever boot the system).

If you're lucky, you'll find traces of the attacker left in the web server logs or ftp logs. Depending on the level of access, you might also be able to find something in the auth logs. Obviously, check through any logs the system offers - maybe you'll get lucky.


Determine SSL/TLS version using Wireshark Using Wireshark, I am trying to determine the version of SSL/TLS that is being used with the encryption of data between a client workstation and another workstation on the same LAN running SQL Server. Documentation on this subject suggests to look at the ServerHello and ClientHello messages but I cannot see any such messages in the Wireshark message feed. I am using this display filter:

tcp.len>1 && tcp.port==1433

I can confirm that encryption of data is occurring and that the packets displayed using the above filter are related to the SQL Server data transfer that I am wanting to examine. This is what the Wireshark message feed looks like:

EDIT:

Here is the packet details pane of the 4th packet after invoking a database connection and selecting Follow-->TCP Stream:

This is what I see when analyzing using Microsoft Message Analyzer. The TLS details pane is for the Client Hello packet.

(Adding a new answer which should be definitive, leaving the old around as it's useful debug for how we got here.  Credit for pointing to the actual answer in comments goes to @P4cK3tHuNt3R and @dave_thompson_085)

  Using Wireshark, I am trying to determine the version of SSL/TLS that
  is being used with the encryption of data between a client workstation
  and another workstation on the same LAN running SQL Server.

You are viewing a connection which uses MS-TDS ("Tabular Data Stream Protocol"):

...the Tabular Data Stream Protocol, which facilitates interaction with
a database server and provides for authentication and channel encryption
negotiation; specification of requests in SQL (including Bulk Insert);
invocation of a stored procedure, also known as a Remote Procedure Call
(RPC); returning of data; and Transaction Manager Requests. It is an
application layer request/response protocol.

If you view the TDS protocol documentation, it specifies that the SSL packets are encapsulated within a TDS wrapper:

A TLS/SSL negotiation packet is a PRELOGIN (0x12) packet header encapsulated
with TLS/SSL payload.

In the Microsoft Message Analyzer screencap you posted, we can see the TDS header (boxed in Red, starts with 0x12), followed several bytes later by the TLS CLIENT_HELLO packet (boxed in Blue, starts with 0x16 0x03 0x03):

0x16 is the TLS "Handshake" header indicator,
0x03 0x03 is the TLS version (TLS 1.2, as per RFC 5246):

The version of the protocol being employed.  This document
describes TLS Version 1.2, which uses the version { 3, 3 }.  The
version value 3.3 is historical, deriving from the use of {3, 1}
for TLS 1.0.

So the simple answer to your question, "determine the version of SSL/TLS", is "TLS 1.2".

Now, I've seen varying reports as to whether Wireshark can properly parse TDS packets with encoded TLS.  I think that the answer is what you started with - it will tell you TLS is there, but won't parse the details as it would with a native TLS session.

As per this StackOverflow question, it appears that Microsoft Network Monitor is capable of parsing both levels of encapsulation.  And a comment therein states that Microsoft Message Analyzer is the newer equivalent of that tool.


Can HMAC confirm message existence? I was looking into HMACs and was wondering if a HMAC can verify the existence of a message.

I need to verify another host is (still) holding a large piece of data. I plan to send the host a key and expect a computed hash back. I am considering one of the below methods for the host to generate a unique key confirming the data's continued existence:

Hash(Encrypt(k, m))
HMAC(k, m)

I am concerned there might be a way to hash the data, store the hash, and use the hash in the HMAC computation, similar to length extension attacks.

I am using Keccak which as I understand it, should be resistant to this.

Thank you!

EDIT: Cross referencing Crypto oriented question on cryptostack

What you need here is properly called randomized hashing: conceptually, a family of secure hash functions, out of which you pick members at random and use those to hash the message.  Typically these are implemented as two-arguement functions that take a "key" or "salt" as first argument, but it's important to understand that this "key" is (potentially) not meant to be secret—they may be revealed to adversaries.

MACs in general don't make good randomized hashes, because the standard MAC security goal is for secret keys—keys that are known only to honest parties, and not adversaries.  But HMAC in spite of the name is more than just a MAC—it's built on a secure hash function, so it can be used both as a MAC and as a randomized hash function.

So the short answer is yes, but don't be confused by HMAC's name in this case; HMAC works here because it's a good hash function, not because it's a good MAC.  And if you have a good hash function you don't need HMAC for this—hash(salt || msg) should work just fine.  I'd use HMAC, nevertheless.


Why don't despotic countries simply block all encrypted traffic? This is a question I often think of when I hear about countries considering blocking just one protocol with encryption, such as tor: How would a resourceful government block tor.  Clearly France wouldn't consider a total ban on all encrypted traffic, but one could make a strong argument for doing so in a country where laws prohibit disloyal, disunifying or critical communication.

It seems though that even countries with poor human rights records allow encrypted traffic, while restricting all traffic to application level proxies that speak only unecrypted HTTP would certainly solve the problem, in as much as unmonitored communication by citizens can be seen as a problem.  Why don't we see totalitarian limits on the internet itself more broadly?

Regarding the comments, if you put a ban on "uninterpretable communications on the people's internet", you'd immediately ban HTTPS, which is mostly invisible to both users and web designers, but also anything a bureaucrat counldn't off the cuff interpret easily would stick out.  You could certainly deliver encryption technology in the clear via javascript, where it can be intercepted and mucked with, but it's hard to see how a combination of inconvenience, attacks by government and social pressure allow that to be a workable solution.

To clarify, I'm asking what is to be lost when a country decides that it must be able to view, analyze and modify all communications to and from its citizens online.  That western websites often use HTTPS is a good argument, and a kind of surprising one, given that social media seems to be a primary weapon against despots.

Because HTTPS underpins a lot of websites. Anywhere you authenticate, you should be using HTTPS. So that's things like:

banking
social media
government sites like tax submission
anything with an account

If you suddenly took away HTTPS, you'd be ensuring that any authentication traffic would be gone. It's not like you can petition Facebook and Goldman-Sachs to create HTTP-only versions of their websites. If the government tried to implement an HTTP-Only* authentication model for internal services, it would be a useless service. You'd be able to grab credentials easily, casting doubt on everyone's online identity.
Simply being on the same network as someone (say, your despotic leader) and running a packet dumper on your machine will capture their credentials, and there's nothing they can do about it.

Blocking all HTTPS traffic would be highly disruptive to a country's online activities, and would stamp out the very thing they are trying to monitor.

* encryption-less, port 80 only, etc.


How to check if a Wi-Fi network is safe to connect to? I always feel scared to connect to hotel, airport Wi-Fi etc. I feel that if the Wi-Fi router is hacked, my personal information can be collected by a hacker. How can I determine if a Wi-Fi network is safe to connect to?

Also, what can an adversary do if he hacks the router I connect to? For example, can he obtain my browsing history? Can he obtain my login credentials if I log in to Gmail? Can he see the emails I sent using the network? Can he install malware onto my mobile? Can he disable the encryption somehow? Can he create some backdoor on my laptop/mobile and access it remotely?

Edit: I got some pretty good answers when the adversary doesn't have control over the router (like arp attacks, mitm attacks). What can an adversary do if he has control over the router?

Can you tell if the network you're attached to, assuming you're just an average user, has a been compromised?

No

  What can an attacker do if they're on the same network as you?

Regardless if you're connected to an open access point, an access point with WEP enabled (hopefully not) or an access point with WPA/WPA2 you can be attacked. Many public places have WiFi with WPA2 enabled and they just freely give out the password. You're still at risk.

An attacker doesn't need to compromise a router to attack you on a public network. It's very easy to arp spoof the entire network and pretend to be the router. Then all your traffic will pass through them. It'd be seamless to your experience

Once the arp spoof and ipv#_forwarding is configured it's trivial to sniff your traffic, inject malicious javascript into http traffic, etc etc etc.

The attacker doesn't even need to arp spoof you to attack your machine though. Just being on the same network as the attacker gives them the ability to scan your machine for open ports, vulnerable services running, start probing your machine.

Using tools such as nmap to first scan the network for potential targets and then port scanning each target, an attacker can quickly find you and identify any possible holes in your machine. Nmap even has some nifty passive scanning features where it won't even expose the attacker on the network because it just listens to who's transmitting instead of actively probing.

  How can you mitigate risk?

Always use TLS and if you can, connect to a VPN whenever you're on a public wifi. Make sure that you don't have any unnecessary services running on your machine that are open to the network. Honestly, you probably shouldn't have any ports open. Any openings are potential access points. Also make sure your machine is fully patched and running all available firewall services.

Mind you this is all just mitigation. If you're connecting to public wifi points you have some accepted risk.

Some reference material for you:

If you want to dig in a little deeper into what can be done, how and with what tools, please look at these links below. To do what I've described above has a very low barrier of entry.

What is NMAP

What is Man in the Middle Attacks?

What is arp spoofing?

What are beef hooks?

What is MiTM Framwork?

What is SSLStrip?

Bonus:

  How do you see what ports are open and listening on Windows?

Open a command prompt
Run netstat -ano | FIND /N "LISTEN"

The output will show you all the ports that are open and listening internally and externally. The one's marked with 127.0.0.1 you can ignore because those are only visible internally to your machine.

Anything marked as 0.0.0.0:Port will be visible to attackers on the network. Also anything marked with private addresses such as

10.0.0.0 to 10.255.255.255
172.16.0.0 to 172.31.255.255
192.168.0.0 to 192.168.255.255

will be visible.

The command and results are almost the same on Linux

netstat -ano | grep LISTEN

  How to identify what services are running on your listening ports

From an elevated command prompt run
netstat -a -b and look for ports marked as listening. You'll see the name of the service in brackets.

Final Note

I use this attack pattern all the time to test devices on my home network for weaknesses. My favorite is testing my phone apps for random things they're sending over the internet. Anyone with a live boot of kali or parrot os can have this attack up and running in about 5 minutes. Last year I even wrote a tool that does most of this for you and injects javascript miners into public networks. You can find my article about it here


Is MD5 suitable for single sign on? We are using an application which offers single sign to their systems which is then embedded as an iframe (i.e. the URL is visible in the source of the page)

The SSO security comes from using MD5 to hash a number of components together and the resulting hash is then used in the URL.

For example, there is a server key and that gets mixed with the user email address and the current date so assuming the server key is ABCDEF, the date is 20161007125600 and the email is bob@acme.com

When this gets hashed it creates a hash of 973897b9cdc4381ae4202a162d28052d and the URL for the iframe is then something like:

https://server.com?hash=973897b9cdc4381ae4202a162d28052d

Assuming I can decrypt the hash I end up with:

ABCDEFbob@acme.com20161007125600

As all the strings use the exact same layout I can pretty easily split this into the email address, the date and the key. By doing so I can now create a hash of ABCDEFjohn@test.com201610071257 and pass the MD5 of that into the URL and login as john@test.com

Is this "secure"? Am I over analyzing this? They are quite a large and established company so I would assume they have tested this extensively but I am so averse to MD5 that it has set my senses tingling and I want to find out if it is something to worry about.

You are absolutely not over-analyzing. What they are doing is not secure. The reason doesn't have only to do with the fact that they're using MD5. It is rather that so called "keyed hashes" (which is basically what you describe) are not considered secure. The alternative method is HMAC. See the description on wikipedia. The flaw I'm referring to above is described in the paragraph "design principles".


Is SSH secure and what are the recommended modes of operation? Given the recent confirmation of weakened and broken encryption schemes and implementations, how does the community feel about the security of SSH?

It seems there has been very little discussion relating to SSH in the context of these leaks.

Additionally what configuration would be recommended to harden SSH?

The SSH protocol is from the same era as SSL (the 1990s) and shares a lot of common principles. Both are relatively complex assemblies of several cryptographic algorithms, and SSL in particular served as a testbed for many novel attack techniques related to side-channel leaks (see this answer for a summary of attacks which have met some success with some versions or implementations of SSL). SSH seems to have less suffered from SSL, mostly because:

It is a lower-value target. A cryptanalytic paper which breaks some facet of SSL is more likely to get some non-academic attention than a similar paper which concentrates on SSH; and "attention" correlates (loosely, but still) with prospects of future funding.
SSL is used in HTTPS, i.e. the Web, and Web browsers are marvelous engines that can, in particular, run the attacker's code (with Javascript). Thus, chosen-plaintext attacks are much easier to demonstrate with SSL than with SSH.
SSL's public key management relies on X.509 certificates, and thus inherited all the relevant troubles. The public key distribution in SSH is much more primitive and lacks the flexibility of X.509, but it is also much harder to break (the SSL model strives to allow a client to securely connect to a server to which the client has never talked to yet; in the SSH model it is merely asserted that this problem is handled "out of band").

In any case, the developers of OpenSSH (the main SSH implementation nowadays) keep an eye on known attacks on SSL; and for the elementary cryptographic algorithms, OpenSSH uses the code from OpenSSL (the very classic and widely used opensource implementation of SSL). Thus, some attacks on SSL which could have been adapted to SSH have been preemptively countered that way.

The cryptographer's point of view is thus that the SSH protocol is roughly on par with SSL. SSL is the most attacked communication protocol, but also the most repaired, and every single novel attack has been tried against it, so we may say that SSL (and thus SSH too) is extremely secure -- as long as you dutifully apply security updates on implementations.

When looked at closely, you will see some cryptographic-level differences between SSL and SSH:

The SSHv2 protocol always uses a Diffie-Hellman key exchange; the server's private key is used only for a signature. This is similar to the "DHE" cipher suites in SSL, and provides Perfect Forward Secrecy. This is a good thing (it means that stealing the private key of a server does not allow decrypting previous connections that the attacker could have recorded).
The symmetric encryption layer combines encryption and a MAC in a mode known as "encrypt-and-MAC", distinct from the "MAC-then-encrypt" used by SSL (see this question for details). Both modes, though, are relatively poor, and require great implementation care to be secure (OpenSSH developers did take care).

In practice, the biggest vulnerability of SSH, by far, is the human user. Servers get broken into through SSH, not because of a cryptographic vulnerability of the protocol, but because either some remote hole was found and exploited in the server code, or the user's password or private key was stolen (typically because of some client-side malware). The really important step that must be taken is to make sure that security updates on both the server and the client are applied with all the possible alacrity.

Remember that SSH is, by nature, a way to remotely control a machine. It is a hole in the server's defence perimeter. A user who can SSH into a machine can then potentially run every possible "local exploit" against that machine. Believing that a given computer is safe against local privilege escalation would be overly optimistic; making the system secure against remote exploits is already hard work. Therefore, don't give SSH accounts away needlessly.

And use a strong password ! (See this for inspiration.)


How do you keep track of numerous keys in the workplace? Where I'm currently working there is a policy where various assets (including laptops) have to be cable locked and in the tech support department we have so many transient assets it's becoming unfeasible to manage all the keys. I need a new system and perhaps purchase equipment.

The problem is it's the nature of the department to take an asset or collection of assets, for example a fleet of new laptops, for a couple days. It becomes really hard keeping track of where the keys for the particular laptops go and if there's a change such as the laptops wont be going out for another week then it's easy to forget where the keys are. As far as I can tell there's no way to identify a particular key with a cable lock. The keys have numbers on them but the locks do not.

What I'm trying to do is keep the keys in a particular drawer of my desk. This hasn't been working well. I already have key chain for keys to shared cabinets and I'm thinking of getting a key chain to keep keys for cables locks on temporary assets. Also someone suggested getting a labeling machine to put labels on the cable locks, though I'm not sure how this would help.

Any suggestions? Things are getting really bad.

EDIT: all cable locks are supposed to have two keys (though this isn't always the case). What should I do with the second one?

You need a key cabinet.  You've probably seen them behind the counter at car dealers, car rental agencies, service stations with garages attached, etc. etc.  I've seen server rooms which had one as it was a good central location for various office keys.  Add some disposable key tags so you'll know which key goes with which lock for the duration of their stay.  If tagging both is a problem, you can also get some of those little colored dot stickers to use to mark which lock goes with which key.

You can usually leave the cabinet itself unlocked during the day, not lock after each access, if there are people in the office and it's reasonably controlled.

Another alternative is to bag incoming keys & locks with a label to hand back out when the device leaves - use your own (static, unchanging) locks to secure devices while they're in your care.  That way you're still keeping track of extra keys, but they're your extra keys, which can make it easier.

If you have two keys... keep them together and let the next guy worry about what to do with the spare :)


HTML5 App can access Browsing-History? I hope this is the right place to ask this question. I am currently discussing with a colleague if it's possible to get the browsing history of a visitor of my site with a special HTML5-Application.

Let's say the user visited Amazon.com, Facebook.com and then navigates to my site example.com where he uses an HTML5-App.

My Colleague claims that using the History-API (https://developer.mozilla.org/en-US/docs/Web/API/History_API or http://diveintohtml5.info/history.html) I should be able to see that the user visited Amazon.com and Facebook.com before. Why? Because in order to manipulate the browsing history, the HTML5-App needs to read the history first. Is this true? I can't really believe it.

If it's not true, can you explain to me how exactly this History-API works?

I should be able to see that the user visited Amazon.com and Facebook.com before.

No, you can't arbitrarily access the browsing history.

You can find out how many entries the history has (history.length).
You can navigate back to any of these history entries (e.g. history.go(-2)).
You cannot learn what these entries are, neither the domain nor the URL.

  in order to manipulate the browsing history, the HTML5-App needs to read the history first.

Well, details of the previous entries exist in memory, but the browser hides them from content scripts. Otherwise, being able to access the history cross-domain would obviously cause massive privacy problems. Just imagine one of the previous sites had a password reset token in the URL.

  If it's not true, can you explain to me how exactly this History-API works?

In HTML5 you can manipulate the state of the history stack, e.g. using  history.pushState(). This is particularly useful for websites with lots AJAX interaction that want to change the URL without reloading the entire page.1 But you can only change the URL to paths that belong to the same domain and you can only access the state objects for the current page. You can find additional security considerations in this security review of the API by Mozilla.

(Note that in the past there have been lots of browsing history leak vulnerabilities that could disclose visited URLs through side channels, e.g. by abusing CSS properties. But these attacks aren't directly related to the API.)

1It can also be useful for an attacker who wants to hide reflected XSS in the URL by dynamically changing the path to something less suspicious. That's why back then this extension of the API has been somewhat controversial.


Will the cookies crumble when it comes to proxy servers? One important use of proxy servers as I understand reading Wikipedia is to keep you anonymous from other servers by acting as a middle-man. If that is indeed the case, consider the following situation.

You access a server without any proxy
The server sends some cookies
The cookies are saved on your computer
You disconnects from the server and reconnects through the proxy

At this point wouldn't the server read the previous cookies and understand what your previous IP was? Now that the server has both IPs in its log, couldn't it tie this proxy and its real client to the same address in the future?

I must confess that my knowledge in the area is very poor. Except reading the online resources and general definitions, I have no way of knowing such specific details. It would be very helpful if you could provide an answer directly addressing the issue that I've mentioned (if there is one).

You're not missing anything -- cookies absolutely can identify you when behind a proxy, and you absolutely can link proxy and non-proxy IPs. The catch is that proxies can have many users, so linking the IPs may not be correct -- not all connections from the proxy are from the person with that non-proxy IP address. But if you don't want a site to be able to identify you, merely using a proxy isn't enough (as they can also use cookies to trace you).


Why don't security systems prevent against password incrementing? A lot of users, myself included, increment the last digits of a password when it is required to be changed on a regular basis - e.g. 30/60/90 days.

Regardless of whether forced password changes are an effective security control, is there not a way to identify similar passwords and prevent them being set; and if there is a way, why is it not routinely employed?

For example:

Consider the new password (plain text) and the hash of the current password
Identify any digits at the beginning or end of the new password and sequentially generate 100 variations (e.g. Password55 -> Password54,Password53 etc,Password56,Password57 etc.) to identify common increments.
If any of the resulting hashes match the current hash, deny the password change on the basis it is too similar to the existing password.

This feature doesn't appear to be an available setting in Windows (at least) and I'm curious to understand why.

Cheers

I guess this is wilde guessing which is not worth it. Should you only identify numbers?  How may? Why not identify characters? If I am setting my password to be "secret10", the system would save Hash("secret10") as my password hash and Hash("secret11"), Hash("secret12")... to be hashes, which I would not be allowed to use in future. But this system already breaks when I set my next password to "Secret11". The system is not capable of identifying the changed upper case! Comparing hashes with even the slightes logic is not possible. Since even the slightest change will break the Hash. And if you want to design a secure system based on passwords, it is more impartant to use hashes than to check for changes in the passwords.


Can a VPN avoid the Prism Surveillance Programme? This is causing me major concern and i can understand it is for a lot of users as well. I have nothing to hide but it's the moral aspect of snooping which has ticked me off.

  Can a VPN avoid the Prism Surveillance Programme?

Meaning will a VPN prevent the exposure and collection of personal data?

From my understanding it prevents the tracking of visited sites and physical location but can it do more than just that?

There isn't really enough information out there to know exactly what is being collected, but if most of it is meta data in nature or user records from services, then a VPN isn't really relevant.

For the first situation (phone/Internet connection meta-data), the contents are not being requested, but only what connections are made.  While the contents of your IP traffic are protected by a VPN, unless a time delay is incorporated, it is fairly easy to match an incoming and outgoing packet based on timing in most cases.  Thus, it would likely still be completely possible for your VPN traffic to be traced without revealing the contents.

As for the access to user data, if you are putting information out there and it is associated with your account on one of the companies, there has never been reason to think that the government couldn't get it if they had a legitimate reason to need to and a VPN wouldn't help there at all.

The real question raised by the PRISM disclosure isn't so much if such mechanisms are possible (It's been very well known that it COULD be done and that in itself isn't news.)  The news is the scale at which they have been doing it and the question is if the government has a right to do so or not.


How secure is a password app that stores both the password and two factor secret in one place? Take for example 1Password, that now can store your password and one time password secret in a single place (your 1Password vault).

I know it isn't truly two-factor anymore, but how much better is it compared to single factor authentication?

To be more clear, say I have a Dropbox account with two factor authentication enabled, and I store both my Dropbox password and OTP secret in 1Password -- thus both accessible by one factor, my 1Password master password. Assuming I have a strong master password, and my Dropbox password is strong and isn't repeated anywhere, is there any security to gain from using two factor for Dropbox?

Yes, there is a slight security gain from having two-factor authentication (2FA) enabled on a site even when you store the 2FA generation/reset code in your password manager. In a scenario where the attacker can monitor your keystrokes or the credentials you're sending to the website but not download your password database, they would not be able to logon to your account with 2FA enabled because they wouldn't be able to determine your seed/reset code. It's not a common scenario, but a script kiddy might get keylogger software while not having the technical skill to find and steal your password database. A man-in-the-middle attack would also collect your credentials without having access to your password database.

A better solution would be to keep your 2FA generation/reset codes in a separate password database, locked with a password kept in your primary one and stored in a separate location. Then even someone with your password database and your master key will be unable to access your accounts protected with 2FA, and you'll be able to recover your accounts if your cell phone (or other 2FA device) is lost.


How to eradicate and recover a compromised network I have a somewhat broad question related to a specific, ongoing threat that I am trying to define and defend against.

Right now, I need to rebuild a secure access point for my mobile devices and computers to connect to the Internet. I will be using a VPN, however, I am wondering about other strategies there are to defend myself. I am currently following NIST: Computer Security Incident Handling Guide
to get a starting point for handling current and future incidents.

Problem:

I have an internet gateway that is provided by an ISP and it has been taken over by an attacker. I believe that it initial attack vector originated from an infected USB stick. Whatever it was it now affects the gateway completely, taking over hardware context, logs and the firewall. The MAC addresses for the Ethernet inputs have changed to a weird (generic?) one and it seems to be getting attached to packets coming in and out. The MAC and log settings will not change by my attempts even with a wired connection to the administrative Ethernet socket.

The WiFi is emitting a new signal in tandem with the original and connected devices begin to emit odd packets with the above MAC address attached to it, although the device doesn't have to be using the Ethernet.

Attempts:

Devices: I tried reinstalling the OS on machines emitting the strange signals. Updates may also be introducing new malware and backdoors.

Gateway: Factory resets and updates do not seem to help.

Current Situation
I feel targeted by the attacker as if each attack seems personal to my profession. I've filed a police report and IC3 complaint, though I wish to know if I can rebuild safely or securely with a driven and skilled attacker(s).

What I am asking

How would one create a secure build on the ISP's Gateway Unit? Would the unit need to be replaced or could there be a way to flash the firmware back to factory values?

And would there be a way to protect my devices from a malicious access point?

I have done this on a large scale at an enterprise. What we did was create an air gapped network with a new drop from an ISP, and AD servers this got us a stable and reasonably secure baseline. Then we created new VLANs on the core network where we switched user groups over on a scheduled basis, ensuring each was quarantined/reimaged and brought in to the new network. Creating a corporate wide new infrastructure was not in the budget, which is why we used the new VLANs on the core.

For a home network where the goal is to build a new network, I would perform a factory reset on your gateway, then do you have a "clean machine"? I would use that to reset your WiFI with all new passwords and bring one machine online at a time, can you see a problem when one machine connects? Personally it does sound a bit like the VPNFilter malware, but that is just a guess.


Which services are affected by Heartbleed? I have to admit that I'm confused as to which services exactly are affected by Heartbleed. I have read http://heartbleed.com but all I read is that OpenSSL is affected. Great, but I don't really know where OpenSSL is used.

So concretely, are these services affected:

HTTPS (OK this one I think I know the answer)
SSH
HTTP
others?

If I have a server which doesn't provide HTTPS (only HTTP), does that mean the server can't be affected by the bug?

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1, which was released on 14th of March 2012. It remained present through to version 1.0.1f (inclusive) and was fixed in 1.0.1g, released on 7th of April 2014  .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

SSH is not affected (SSH is a different protocol to TLS)
HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.

So in summary:

The only apps/services that are affected are those that use a vulnerable version of OpenSSL for TLS connections, and have TLS heartbeat support.

Other TLS libraries (like GnuTLS, SChannel, and JSSE) cannot possibly be affected by this particular bug, because it only exists in specific versions of the OpenSSL library.
If you are unsure, ask the person/company that wrote the application.
If you are a developer, find out what library your app is using for TLS connections and test to be certain.


Why PEM encodings of EC public and private keys use different headers? Manual page for OpenSSL ec command states:

   The PEM private key format uses the header and footer lines:

    -----BEGIN EC PRIVATE KEY-----
    -----END EC PRIVATE KEY-----

   The PEM public key format uses the header and footer lines:

    -----BEGIN PUBLIC KEY-----
    -----END PUBLIC KEY-----

What standard does this base upon (if any)?
Why 'EC' is indicated in the private key header/footer, but not in the public? I assume that this is a piece of "meta-information" describing the content, so why is it missing from the public part?

To answer your first question, this is based on the RFC https://tools.ietf.org/html/rfc5915 (section 4)

The missing algorithm name has to do with the encoding format used while encoding i.e. pkcs#1 vs pkcs#8. The first one doesn't contain the algorithmIdentifier and hence the algo name(EC, RSA etc.) is included in the label. However, pkcs#8 encapsulates the algorithm identifier and hence it's omitted from the label.

for example, pkcs#8 format for private key is this:

PrivateKeyInfo ::= SEQUENCE {
   version                   Version,
   privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
   privateKey                PrivateKey,
   attributes           [0]  IMPLICIT Attributes OPTIONAL }

Version ::= INTEGER

PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier

PrivateKey ::= OCTET STRING

Attributes ::= SET OF Attribute

To clarify, there is nothing preventing one to represent the public key in pkcs#1 format and thus creating a header of the type: -----BEGIN EC PUBLIC KEY-----. So it seems that the particular encoding produced is according to the default encoding set for the tool(I am not sure of this though). Nevertheless, any decent tool/library should be able to gracefully handle either format, even when different formats are used for the public and private keys of the same key-pair.


Cardholder info transmission between issuing and acquiring banks Which data is actually transmitted between issuing and acquiring banks during various phases of a card payment transaction?

Specifically, does the Issuer tell the Acquirer any info (and which if any?) not originally acquired from the Cardholder by the Acquirer? E.g., when doing a purchase on a website not asking the cardholder's name - does the Issuer tell the Acquirer this name at some point?

Typically the issuer does not provide such information to the acquirer/merchant.

It will only provide information about the authorization of a transaction (ie accept / decline etc). It will, in specific circumstances if asked, confirm that the address provided by the customer matches the address held on record (the Address Verification Service or AVS) but again it's a confirmation of the information provided by the merchant/acquirer, the issuer wouldn't separately provide the addresses.

If you look carefully you can find the card scheme message formats on the internet.


What "timing attacks" could websites perform using last modified dates of files? https://developer.mozilla.org/en-US/docs/Web/API/File/lastModified describes the .lastModified property of a File object in JavaScript (usually created when a user selects a file via a HTML <input type="file"> element; in-browser JavaScript served from a web page of course does not have limitless access to the user's file system!)

The docs contain the following cryptic security remark:

  To offer protection against timing attacks and fingerprinting, the precision of someFile.lastModified might get rounded depending on browser settings.
  In Firefox, the privacy.reduceTimerPrecision  preference is enabled by default and defaults to 20us in Firefox 59; in 60 it will be 2ms.

At a real stretch I can see how, hypothetically, file modification dates could be used for fingerprinting: if you can get a user select the same file in an <input type="file"> dialog on multiple sites, and you store the accurate-to-the-microsecond file modification date, then you can cross-reference them and notice that, voila, it's the same user (although this seems like a wildly far-fetched scenario!). But I'm at a total loss to imagine what "timing attacks" this rounding could protect against.

What are the attacks that this feature is actually supposed to prevent?

I don't think there is a timing attack specifically against File.lastModified. I think the reduced precision of the lastModified field is an effect of a mitigation for all kinds of timing attacks.

Spectre/Meltdown were exploitable from JavaScript, by timing certain statements. For this, you would need high-precision timing. To solve this issue, Mozilla reduced the precision of the timer with privacy.reduceTimerPrecision. This must affect all timers: if the someFile.lastModified is more precise than new Date() or some other timer, you could build a precise timer by changing a file and then looking at the lastModified.


Invalid Certificate when adding Gmail account to Apple Mail Trouble seemed to start after upgrading to OS X 10.9.  I stopped receiving email in an account I'd set up over a year ago.  I removed the account and when I attempted to add it again, I was served a message about the identity of my domain name not being verifiable.  Not suggesting it has anything to do with the OS X upgrade, just providing related details.

As of right now, I'm unable to find any info about agoragr.gr and it has me confused/concerned.

Any insight into this would be greatly appreciated.

Mark

Renew the certificate on the domain, if you can't contact the administrators.


Metasploit Get Shell Through NAT Ok first of all this is legal and I have it in writing my friend and I are attacking eachother to get better and not break the law.

Setup
I have a VMWare image running BT5R3. It uses VMWare's NAT then my network is behind a router using NAT. From there I am VPN tunneled into work which also uses NAT (I believe). I've come to realize that I have only ever run metasploit from the inside or in a lab but never over the internet.

Question
I'm pretty sure with this scenario a reverse payload wouldn't be possible since it requires the machine to connect back to me. Will this work with any payload at all?

This won't work with reverse payloads unless you can do portforwarding on the system which is NATing your traffic. Hence it's better to generate a payload which allows you to connect to it rather than a payload which connects back (but if your target is also using NAT, then this becomes obsolete as well). For instance:

shell/bind_tcp

This does give problems if there is a firewall between you and the target. Best thing to do is take away the NAT completely if possible. In your case this seems quite difficult...


Securing the security guy's home office: what should we do? I read an article in the latest InfoSecurity magazine (an infosec trade rag by Elsevier) saying that us security professionals aren't necessarily taking the correct steps to protect our own home office networks and computers. Now as a security consultant who operates out of my own home office, I ask you how you protect your home office? What should we be doing?

Using my own environment as an example, I go to great lengths to protect my clients' source code (I'm in app security). I also use WPA2 on the router and change the password every so often to try to avoid network sniffing. I have a firewall on each computer, though maybe I don't review the logs as often as I might... and I have backups both locally and offsite. And of course the hardware itself is insured.

So, what have I missed? What would you do? What wouldn't you do? Of course, policies aren't such a good solution because there's only one of me, and I'm not about to fire him ;-)

I did a bit of an article on this in the Financial Times 3 or 4 years back but can't find more than the headline piece. Anyway, as I tend to practice what I preach, I have my home set up with networks separated by risk -

I have one wireless router with two
networks which only connect to the
Internet. A DMZ which just uses WEP
in order for my kids to use their
Nintendo DS's online and another
which is for my local community free
wireless
Another router hosts a secure WPA2
network (mostly for my Playstation 3)
For the wired networks, I have a low
sensitivity network for the rest of
the family - who connect using VMs I
have built for them, and a higher
sensitivity network for most of my
research and non-client activity.
For security testing work for clients
I have a higher security subnet which
requires strong multifactor authentication

For platforms, I have always found the simplest is to use a hardened build for client testing, which can be broken down after testing and reporting is complete. The build has BIOS password and full disk encryption. All machines and servers on all my networks also have firewalls and antivirus and are patched up to date as per vendor guidance.

If you have a security guy working from home, you may find it difficult to audit the kit on site, which can be a problem in terms of managing the risk from them. You typically don't have many solutions here, as they have physical possession of the kit and are effectively unsupervised - understand how much you need to trust them, ensure your contract is appropriate and configure logging as appropriate.

I agree you do need physical security - not only on doors, safes and computer tethers, but also on paper documentation and archives/backups.

Backups and insurance are essential! I use encrypted backups on a site very unlikely to be within the blast radius if my house happens to have a plane land on it (could happen - I'm only a couple of miles off the approach to Edinburgh Airport)


What is the best way to verify the SSL configuration of my web server? How do I ensure I have my SSL configuration setup securely?

SSL Labs rocks for verifying all the nuances of a proper SSL setup - just put your domain name in and hit submit:

https://www.ssllabs.com/


Can a second router be used as an artificial firewall? I was wondering if I can make an artificial firewall by using two routers (Referred as Router 1 and Router 2). My server will be on router #1 while router #2 hosts all the other devices on my network. I was thinking that router #2 could be a total separate "entity" and appear as a singular device on the network. So if people breach the server only router #1 will be breached, and router #2 could still stay protected. Ill try to show you in a more visual way.

Router#1 (192.168.0.1) /Server "FreeBSD 10.0" (192.168.0.2), Router#2 (192.168.0.3)

As you can see Router #2 would look like any normal device to Router #1

(it will look like 192.168.0.3 to router #1) Router #2 (192.168.1.1)/ PC "Windows 7" (192.168.1.2), PC "Windows 8.1" (192.168.1.2)

Will this setup work, has it been done before, these are my questions.
What can I do to make this work?

Assuming the routers you are using have stateful access lists then they can be used as basic network firewalls and the design you have will provide some very basic defense in-depth benefits. If it's a possibility you may want to block all inbound packets initiated by the Free-BSD server entering the second router (clients behind the second router can still access the server but not vice-versa because TCP ACK 0 packets inbound to the internal network will be blocked).

Will it work ? yes but it might be easier if you segment the network ranges so they don't overlap. Maybe use a 192.168.1.x network and a 192.168.2.x network (there's a LOT of ways to do this, I'm just throwing out a really basic example)...

Has this been done before ? Yes, a long time ago before firewalls were popular and inexpensive this is one way people segmented networks.

Note: Just because this works doesn't mean it's a good idea. Some routers temporarily drop their filtering rules when under duress and allow "all" traffic through. Firewalls don't generally behave this way. Likewise almost any firewall will offer a lot of additional features that the routers won't be able to offer you.

If you are on a budget I would highly recommend simply using something like IPTables or PFSense.

As a side note if your First router has 3 interfaces you can also use one interface to connect to the Internet, a second for your Free-BSD server and then use the third for your internal network and not need the second router to create the same type of segmentation. (think Y-shaped network diagram)


Why would you maintain multiple session ID's in one application? There is a web application and I am looking at the cookies values after authentication using Burp proxy. There are 5 different cookies, say c1, c2, c3, c4, c5.

When I tampered with the values of c1, c2 and c3, I got a 200 OK response, meaning these cookies don't hold session information.
When I tampered the values of c4 and c5, I got a 302 response and was redirected to the login page. It means that c4 and c5 are session ID's.

My questions are:

Is my understanding right about the site maintaining more than one session ID?
Why would multiple sessions ID's be maintained? Is it to add some security?

Depends.

It is very common to ensure the session cookie integrity. One way is to create a very random (reasonable long) identifier, another way is to sign the session cookie. It is even a MUST with the stateless systems, where the cookie passes the whole user context (very popular today).

So - you can have a cookie containing its signature within (such as JWT token) or another cookie containing MAC of the session cookie. If you fiddle with one of them, the session information becomes invalid.

It may have different reasons as well, such as you've changed the validity information, site-location information, ...


External JS Security I've worked mostly with backend processing stuff.

I've been assigned to figure out how to secure external Javascript that we import from sources like Facebook, Twitter and Google.

One option is locally hosting them, which may not be possible due to updates of the said files:

http://connect.facebook.net/en_US/all.js
https://platform.twitter.com/widgets.js

Can I have any input on any other options that are possible in securing the external Javascript that we are linking in our website?

This has more to do with risk management. You do not have any contract with Facebook or Twitter. So you have a risk that they may change the contents of the JavaScript file without you knowing. This can be malicious or accidental, either way you have no control of this risk.

So unless you get a contract with the external party which moves the liability to them, there is nothing else you can do and you should store the sources locally.


How different should my passwords be? Suppose I use remember one long high entropy master password, and use variations of it for each of my passwords.

Eg if I remember tSaF4nWeACVkUU4 as a master password and use tSaF4nWeACVkUU4t (with a t and the end) as my Twitter password and tSaF4nWeACVkUU4g (with a g at the end) as my Google password.

Is this bad practice if so how much variation should I put in different passwords.

You use distinct passwords on distinct systems because you know that some of these passwords may leak. If your passwords are high enough in entropy then they won't leak through brute force, but they may still leak through some other ways, e.g. server compromise (grabs the passwords as they come by), key loggers (grabs the password as it is typed),... Using distinct passwords is a damage containment feature. To keep server compromises local that server.

If the password for site B can be easily inferred from the password for site A, as in the method you suggest, then you fail at the damage containment. That the password starts with high entropy has no influence whatsoever on that statement. High entropy is about avoiding a breach through brute force (aka "dictionary attack"). However, once another kind of breach has happened, entropy is no longer relevant. Entropy is a measure of what the attacker does not know. If the attacker could grab your password then he knows all of it and there is no entropy any longer. We are past that step.

For damage containment to work, knowledge of your password for site A must yield no information whatsoever about your password for site B -- which means that both passwords must be generated randomly and independently of each other. Notably, while this means that you should not do some "password derivation" as the one you propose, you should not either reject candidate passwords for site B because they would be "not different enough" from the password on site A: such a rejection rule would also help an attacker narrow his brute force efforts.

(Cryptography-powered password derivation from a root password may be applicable, but these things are subtle and, in any case, you won't be able to run it in your head, which voids the usability advantage of having a simple derivation rule.)


Hidden directory with 0x0d0x0a Someone has hidden a directory to fool policies on a FTP account. The directory name was 0x0d0x0a.

How did the user create a folder with that name?

The directory is nearly invisible with ls but discoverable with find.

The directory name is not the string '0x0d0x0a' (which are eight plainly visible characters) but a string consisting of exactly two characters, the ASCII "CR" (carriage return) and "LF" (line feed), which are encoded as two bytes of value 13 (0x0D in hexadecimal) and 10 (0x0A), respectively.

From the point of view of the operating system, file and directory names are just bunches of bytes, with only two special byte values: 0x00 (which terminates the string) and 0x2F (the '/' which separates directory names in a path)(I am assuming a Unix-like server here, but the situation would be similar on a Windows system). Bytes of value 0x0D and 0x0A have no special meaning at all for the kernel. However, tools with a text-based output may be fooled (e.g. it might display the name as a newline, which would not be clearly visible as such in the output).

With a Linux shell, you can create such a directory with this command:

mkdir `printf '\x0d\x0a'`

To do that from a FTP client, you would have to delve into the way the FTP protocol works so as to know how to encode the corresponding MKD command, but I see no conceptual impossibility.


Spooky behaviour with Authy So today I got Authy, (because I wanted 2FA on my google account).

Anyway, it works grand, and I scanned the google QR code and all works well.

One thing is weird though, I have coinbase on my iPhone as I buy bitcoins sometimes. When I launched the Authy app it immediately offered Coinbase codes as well as google codes.

The thing is I didn't use google 2FA for Coinbase, my coinbase account is totally separate from google.

So, minus the fact that I had the coinbase app on my iPhone (and iPhone apps are supposed to be completely sandboxed and don't communicate), how did Authy know I had a coinbase account?

Bonus question, which is the weirdest thing ever, when I went to sign into Coinbase (after having downloaded the authy app), rather than sending me an SMS to my phone, Coinbase ASKED for the Authy code...

Also the Authy app sent me a push notification on my phone to suggest I open it to get my code. How is this POSSIBLE?

I didn't link Authy and coinbase, the ONLY link is my coinbase user name is my google email address... please help explain.

Have a look at the Authy integration guide in the Coinbase docs:

  Install the app on your phone (the exact procedure may vary depending on your device).
  Launch the Authy app. When prompted during setup, enter the phone number you have verified on Coinbase and press OK.
  Choose to receive either a phone call or SMS to retrieve a verification code.
  Check your phone for the SMS or voice message sent by Authy. Note that the number that the code comes from may vary.
  Enter the registration pin that was sent to you via SMS/voice into the Authy app.
  Your phone is now a secure token for your Coinbase account and the Authy app should now have a Coinbase entry. Your Coinbase account will be synced with Authy through your phone number.
  The setup process is now complete. 2-step verification codes will be available under the Coinbase entry in the Authy app and can no longer be sent via SMS or Voice.

(Emphasis my own)

There is no explicit permission step where you authorize Authy to generate tokens for Coinbase. Authy associates your account based on the same confirmed phone number for both Authy and Coinbase.


How do I sanitize and check large numbers that will be sent to an unmanaged BigNum library like GMP? I need to process data that is sent by users in a LargeNumber format.  My current choices are

BigInteger (.Net Managed Code)
IntX (Managed Code, faster for some operations)
GMP / MPIR (Unmanaged code, fastest with a wrapper 1 or 2)

Since dealing with large numbers has the ability to create some floating point errors, and the unmanaged code has the ability to create buffer overflows:

Is there anything I can do to proactively scan and validate large numbers that will be used in these libraries?
Are certain operations more risky than others? (mult vs add)
Are some libraries better than others?  (Is managed code more secure because of bounds checking? .. does it even matter, it's just a number?)
Is it even possible to scan a large number for unusual cases that might cause an overflow?  What would I look for?

A number is a number. When dealing with numbers, there are three steps:

Decode the values from an external representation (e.g. a bunch of bytes which, in your protocol, follow a given convention).
Apply mathematical operations on the values.
Encode the results.

Buffer overflows due to malicious data will occur only in phase 1 and 3, and then quite rarely. During phase 2, there's no issue of that kind (if there is an overflow, then that's a bug in the library itself, but no such bugs is known for existing implementations -- as a rule, developers for mathematical libraries are maniac about tracking and destroying bugs).

As a user of the library, you must take care of the two following things:

When encoding, do not assume that the value "will fit in a given buffer length". Use the library to see the actual length of the value.
When using a lot of multiplications, integers can grow to unbounded sizes, leading to huge memory allocations and heavy CPU consumption. You may want to include checks on the length of integers at various places in your code, to see whether you are dealing with values which are way larger than they should.

I suggest you begin with BigInteger (from .NET) because that's the simplest and it is already there. Envision switching to something else only if you encounter an actual performance issue, duly measured and quantified.

(You will not have any "floating point error" when using integers, by definition. Floating point is quite another domain.)


POODLE and REST APIs Are non-browser applications which do not contain an embedded browser, and merely make REST API calls over HTTPS, vulnerable to POODLE?

And if not, is it unnecessary to disable SSL in such applications?

Poodle is, as presented, a chosen-plaintext attack, although not by a large amount.

At its core, the vulnerability that Poodle builds upon allows an active attacker to try to guess a single byte of cleartext data. The conditions are the following:

The stream uses SSL 3.0 with encryption done with a block cipher in CBC mode.
The byte value that the attacker is interested in is part of the stream, and occurs at the end of a block (blocks have length 8 bytes with 3DES or RC2, 16 bytes with AES).
A subsequent record in the stream (in the same direction) has a length that implies a full-block padding.
The guess has probability 1/256 to work. On failure, the SSL stream is broken, and both client and server know it.

So, in practice, the situation must be such that the attacker can trigger SSL connections silently, and arrange things so that an "interesting secret" is sent through the connection at a predictable place, and the attacker must also be able to alter the sent data size so that each "interesting byte" occurs at the end of a block, and a record with full-block padding also occurs. It is worth noting that the attacker must choose the length of some message elements, but needs not control the contents (this is why it is a CPA only honoris causa). Moreover, each broken connection must not trigger too visible alerts.

A Web browser running hostile Javascript and connected to the Internet through an attacker-controlled WiFi access points fulfils all these conditions. Chances are that your non-browser application does not.

Nevertheless, you should really use TLS 1.0 (or, better yet, TLS 1.1 or 1.2). Now the bright side is that the SSL/TLS handshake is protected against protocol downgrade attacks: if client and server follow the standards, then attackers cannot force a client and server that both know TLS 1.0 to fallback to SSL 3.0. Web browsers have unfortunately got into the unsavoury habit of working around the standards precisely to use SSL 3.0 in case of failure with TLS 1.0. In that respect, browsers are weak to Poodle because they insist on being weak; they favour continuous support of a handful of antique servers that have not been updated since last century, over simply preventing the user from getting hacked up beyond all recognition.

The real problem, though, is that client and server still accept to use SSL 3.0 even though they both know that it is weak. More on that subject here. Disabling SSL 3.0 support and concentrating on TLS 1.0 (that you already use in practice) is not something that you should do because of Poodle; it is something that you should do because it is high time to transition from stone tools to metal. Embrace Bronze Age before it is too late !


How weak is MD5 as a password hashing function ? A professor told us today, that MD5 is weak. I understand his chain of thought but pointed out, that IMHO MD5 is a good way to go if you would use a long (even really long) dynamic salts and static pepper.

He stared at me and said NO!

IMHO the possibility to "brute-force" a md5 hash with a any dictionary is even simple. If you would use a dynamic/various salt it would be hardened to get a match with a complexity of O(2^n) and if I use a pepper before and after my salted password hash it would be not 100% safe but could take a long while to compute it..

There are lots of known cryptographic weaknesses in MD5 which make it unusable as a message digest algorithm, but not all of these also apply in the context of password hashing. But even when we assume that these do not exist, MD5 is still a bad password hashing algorithm for one simple reason: It's too fast.

In any scenario where an attacker obtained the hashed passwords, you have to assume that they also obtained the salt of each password and the pepper.

The only reason to use a pepper is so you can't use a rainbow table precomputed before the attack, because you need a different one for each database. The only reason to use a salt is so you can't use the same rainbow table for the whole password database, because the same password for two different accounts will have a different hash.

The length of pepper and salt don't matter that much. Their only purpose is to make sure that each value is unique. More length doesn't make the attack notably harder (there is more data to hash, but that's a linear increase at most).

Bottom line is, a short salt is all that is needed to make sure that the attacker has to brute-force all possible passwords to find the correct hash for every single account.

And that's where MD5's weakness comes into play: It's a fast and memory-conserving algorithm. That means an attacker can compute the hash of a large number of passwords per second. Using specialized hardware (like FPGA arrays or ASICs) worth a few thousand dollar you can compute the hashes of all possible 8-character passwords for a given salt in mere hours.

For better security, use a slow algorithm like bcrypt. It means that your system needs some more CPU cycles to authenticate users, but the payoff is usually worth it because an attacker will also need a whole lot more processing power to brute-force your password database should they obtain it.


Is it possible to prevent man-in-the-middle attacks in token-based authenticated online games without packets encryption? I'm creating a home made MMO server (as a hobby / way to learn something new). I've decided to use a token based authentication for game traffic.

Many people say that you shouldn't use any kind of packets encryption in case of the authorative-type game servers. Every packet should be validated and we should assume that the clients are transparent. I get it.

But what to do with the possibility of network sniffing and the man-in-the-middle attacks? If you use the token based authentication, you have to send the token together with the data. The token can be eavesdropped and the attacker can impersonate as you. Is there a way to prevent this without using the encryption?

Following to Steffen Ullrich comment I've decided to use HMAC with timestamps and nonces for additional replay attacks protection. This approach should be enough to protect the data against unwanted modifications.


How can document.referrer be used for XSS? A very simple example...

or

I've tried simply sending the request and adding a referrer header, but that doesn't seem to echo onto the page.

Updated browsers will encode the referrer URL.

So your examples will not work to trigger XSS nowadays.

Try this:

JSFIDDLE:

http://jsfiddle.net/y4afy8h9/1/??


A daemon to tell when do apps access the cell phone camera? Unavoidable issue of modern cell phones is that they have a front and rear side camera covering almost a 360deg view. And that some applications like, say Facebook request access for everything. So basically a normal user has at least an app that has camera permissions, and even though they intend to use it rarely, there's no info about when it turns on.

My question is, is there a way to monitor when do apps that have those permissions actually turn on the camera?

(Let's narrow it down to Android)

If you're using CyanogenMod, Privacy Guard has this functionality.

Optionally, disable it in the app's settings and set it to 'Ask' for permission every time, which will give you a warning each time.


If a bank says they do not have my login and password info, is that true? After an investigation on their part, the bank simply states that if someone accessed my accounts via internet banking, (and a simswap) I was the one who didn't secure my login and password info.

I do not have it written down anywhere and didn't click on any suspicious links on any emails that might have been spammed at me. The only way I noticed something was wrong is because of my cellphone, (which never left my side) suddenly giving me a sim error. I contacted my service provider immediately and they apologized grumpily and corrected the error. Knowing the risks, I immediately contacted my bank. this all happened in the space of one hour, but by them it was too late.

Now the bank says it had to have been me, because they don't have my login and password info. My phone is used for verification when I add or change a beneficiary, which is why they needed it to get the money out, but my login and password wasn't on the phone so even if they did do the swap, how did they get my info?

Your bank probably don't have access to your plain text password but it isn't as simple as that.

It is unlikely that your bank store your password in plain text, so it would be a non-trivial task for them to look up your username and password and then login.

However, there are many other potential causes that could lead to an illegitimate transfer from your account - anything from vulnerable systems to rogue bank employees.

If your bank is claiming that they witnessed a login using your username and password that led to the transfer then the question of who's responsible will depend on your bank's fraud policy and the laws of the country you live in.

However, it does sound like you are describing a possible breach of your security so you should take immediate steps to fix this.


How can I know if a USB drive is fully encrypted? When a fully encryped USB drive is connected to a computer, the OS says this USB drive is not formatted. How can I verify that a USB drive is fully encrypted while still being formatted? Is there a certain way to confirm this?

If something is just encrypted it is not really distinguishable from random data, i.e. one cannot say if it is unformatted or encrypted. If instead some container format (like LUKS in Linux) is used for this encryption and the container format is known to the OS then the OS can detect (and will usually also do it) that this is an encrypted container and that some password or similar is needed to access it.


Windows Defender and Windows Processes When I open up task manager, I see windows processes(services) at the bottom. As a programmer, I want to create a windows process/service for security research(windows defender) but I have some questions,

when an executable is run as a windows service and as an administrator, does windows defender still scan it for threads?

Windows Defender, like nearly all antivirus/anti-malware software, runs with extremely privileged access and by default scans everything it can. That definitely includes Windows services, even those running as [LOCAL]SYSTEM (it would actually be somewhat weird to run a service as Administrator; Administrator is a user account, while SYSTEM is a service account. They have equivalent permissions, though.)

Defender also scans files that aren't being executed. That is, it would scan the binary when you either created (compiled) it, or when you moved it onto the system (by downloading, or copying from external storage, or whatever). It might be possible to safely pass the file scan but get caught by the executable scan, depending on the signatures it looks for in each case. It is even slightly possible that the reverse might be true, though that would be weird (and kind of pointless; if you can't pass the file scan you won't have the chance to execute).


How do servers protect against straight up sending a HTTP request that is actually some malware or HTML code? I know servers have something to block you from just sending them an HTTP request that is actually some malware or a webpage that is malicious, because it would be so easy to just spam HTTP requests with malware. Code red used something more advanced than that by spamming an HTTP request with Ns. Also, I wonder if some servers don't have this patched?

Here is an image of the SARS-CoV-2 genome. Will looking at the image give you COVID-19? Of course not. While you could call this the biological equivalent of "malicious code," it doesn't cause any harm unless it's presented in a format and context where it might be "executed."
The same concept applies to computers - code or data that is dangerous in one context can be completely inert in another context. If you send malicious code or data to a web server, unless it's specifically designed to target a flaw in the web server, it will just be treated as data and it will have no meaningful effect.


Capturing multicast packets in WLAN (I had to move this from Network Engineering stack exchange where I origianlly asked this question)

If a device in monitoring mode snoops on the traffic in a WLAN, can it CAPTURE and READ multicast packets?

For instance, if a device broadcasting packets to multicast address 239.255.255.250, can a monitoring device capture and read those packets?

That depends of that packet is encrypted. If you happen to capture a multicast packet sent over an open WLAN, then you can read it without problems.

If the packet is encrypted, then you need the key in order to read the packet successfully.

The reason why you can in general use multicast, is because of the OSI layer model. It simply does not matter to the higher layers how the lower layers are implemented. As such, if a network uses mixed clients (some wired, some wireless), multicast and broadcast still need to work.


How can i get an alert box from this? While testing a website i noticed that the value of parameter username is reflected inside the javascript code of the response. It's insert into a variable like this one:

var valueUser = "my-controlled-value";

How can i trigger an alert box inside the javascript function?

Here's what i tried.

Tried to close the script tag but i get a connection timeout (probably some kind of WAF. I think the only solution is to break the javascript function and trigger the alert
Tried to use this payload test"; alert(1);// but it's not working
Also the only block is that when you insert " it will be converted to \" all the other symbols are not escaped

What payload can i use to make it work and trigger the alert box?

Is \ converted to \\? If not, break out of the string using \"; it'll be converted to \\", which will be treated as a sole (escaped) backslash and then a string-terminating quotation mark.

Inserting a newline will break the string, but also break the JS application. If you don't have some way to recover from that - such as the ability to insert a new script block on the same page - that's probably acceptable, but you already said that closing the script tag (presumably to then open a new one) doesn't work.


Can't upload payload to my apache2 server. Pentesting exercise Im reading "Penetration Testing - A hands-on introduction to Hacking". I'm trying to figure a way out to paste a .exe to my apache2 server and later download it from my VM since these steps from the book doesn't  work:

  First, run
  cp chapter4example.exe /var/www
   to copy the payload executable
  to the Apache directory, and then make sure the web server is started
  wit
  h
  service apache2 start

  root@kali:~#
  cp chapter4example.exe /var/www

  root@kali:~#
  service apache2 start

  Now switch to your Windows XP target and open Internet Explorer.
  Browse to
  http://192.168.x.x/chapter4example.exe (Yes, i do put my ip here)
   and download the file.

But the page returns: "The page cannot be displayed"

My apache2 server is up, and the file is in /var/www.
I think i need to copy the file to another location.

Move it to /var/www/html/example.exe, then go to http://yourip/example.exe to download it.


How to secure my PHP url endpoints I have a backend that I developed on PHP/MySql which will provide some URL endpoints in order to get data or post data. I am using those URL endpoints in my application (WebGL application). Now, the problem is, the URL endpoints are public and anyone can use those URL by simply inspecting the browser. An attacker can get the URL endpoints and may post spam data or hang my server etc. So my question is that how do I save my URL endpoints? Remember there is no login option into my application. The WebGL application is public, anyone can view it. I want to use my URLendpoint form the application only.

An attacker can get the url endpoints and may post spam data

Do you have some means of telling an attacker from a legitimate user?
(Rate of posting, content of post, etc.). Imagine being the server app, and you see a request coming in. Can you tell whether it is legitimate or not?
If yes, then use them - move that reasoning into your application logic. Better still, add this information to your question so you might get further suggestions and insights.
If not, then unfortunately your answer is "You cannot secure your URL endpoints" (because "secure" implies "distinguish between good and bad guys") and you need to look into things like logins, cookies and/or client certificates.
authenticating an application
You need to add something to the application that an attacker can't easily replicate. This requires making assumptions against what an attacker can and can't do.
No one can defend against an omnipotent attacker. So, you cannot say "I want to defend against anyone". You can only defend against someone that cannot do something that your application can.
So, if the attacker has full access to your application source code and secrets, and therefore can learn to do whatever your application can, again you cannot defend against them.
In Android and iOS, there are "secret areas" that you can interface with, and allow doing something an attacker can't. Basically you establish a secret in the protected area, then ask whoever connects to prove they know the secret. This too is imperfect because you're only authenticating the device, not the application.
If the attacker does not have access to the source code, then you can use a classic challenge/response scheme, where the application contains (either the same for all clients or one assigned to each client) a secret string. All calls are GETs for clarity:
The app has a secret and it is "001:MySecret001".

App --> "application/login?auth=001"  --> server
          <--- "tell me the answer to: 2020-07-21-13:36:35-Qa9XtFtp"

App retrieves its secret, it is "MySecret001", calculates the hash
   of the string "MySecret001,2020-07-21-13:36:35-Qa9XtFtp"
   and sees that it is `57703859adcdb4239e513dd7fe991afe`. So...

App --> "application/login?auth=001&challenge= 2020-07-21-13:36:35Qa9XtFtp&response=57703859adcdb4239e513dd7fe991afe"

The server verifies that the response is indeed the hash of the challenge, and that the challenge timestamp is not too old. Then it retrieves the secret for user 001, and sees it is MySecret001. It does the same calculation the client did. If the two hashes are the same, the client is legitimate.
This, as I said, requires that the attacker cannot crack the app and see what the secret is and how it is manipulated.
The login/password scheme is identical, except that login and password are in the head of the user.
authenticating a request
We still (see above) need that the attacker cannot see the application source code. When this is the case, you can modify (maybe using a filter, which is possible with e.g. jQuery) the request, adding a header or an extra variable:

suppose the request is "cmd=add&text=HelloHello&subj=HelloWorld"
you sort the request dictionary in alphabetic order:

cmd = add
subj = HelloWorld
text = HelloHello

you take the secret, or a random string the server sent the application on the first request (called "nonce") and initialize "hash" to this value
for all elements in request:

hash = MD5(MD5(hash + key) + value)

you add "hash=(whatever)" to your request.

The server receives a request, saves "hash", knows the secret shared with that client, and can therefore repeat the calculation and see whether the hash value matches.
An attacker that does not know the initial "secret" value now cannot send arbitrary commands, because they don't know the appropriate value of the hash for that particular command.


Why are certificates limited in time? If a certificate has a limited duration of, say 5 years, but it gets somehow compromised after 2 years, waiting the 3 remaining years for it to get invalid is not a real solution to the breach problem. (3 years is eternity in IT, I guess)

Also, if the encryption method gets cracked (à la WEP), you also need to update everything immediately.

What are the advantages to limit the validity in time (except for the issuer to make money on a regular basis, I mean)?

The technical reason is to keep CRL size under control: CRL list the serial numbers of revoked certificates, but only for certificates which would otherwise be still valid, and in particular not expired. Without an end-of-validity period, revoked certificates would accumulate indefinitely, leading to huge CRL over time.

However, since network bandwidth keeps on increasing, and since modern revocation uses OCSP which does not suffer from such inflation, this technical reason is not the main drive behind certificate expiration. In reality, certificates expire due to the following:

Inertia: we set expiration dates because we have always set expiration dates. Traditions, in information security, often lead to dogma: when security is involved, people feel very inhibited when it comes to changing long-standing habits, in particular when they don't understand why the habit is long-standing in the first place.
Mistrust: ideally, certificate owner should seek a renewal when technological advances are such that their keys become inadequately weak (e.g. they had 768-bit RSA because it was fine back in 1996). But they don't. Expiry dates enforce renewals at predictable moments, allowing for gradual, proactive evolution.
Confusion: expiry dates can be viewed as a translation of housekeeping practices from earlier military cryptosystems, before the advent of the computer, where frequent key renewal was required to cope with the weakness of such systems. Some people think that certificate expiration somehow implements that practice (which is obsolete, but hey, Tradition is Tradition).
Interoperability: existing deployed implementations of X.509 expect certificates with an expiry date; the field is not optional. Moreover, some of these implementation will refuse dates beyond January 2038 (that's the year 2038 problem).
Greed: if you are a CA in the business of selling certificates, well, you really like it when people have to come buy a new one on a yearly basis.


Preventing information disclosure from browser back button/history? I have sensitive data that will be hosted on a website, and I would like to prevent the data from being exposed in this scenario:

The primary user logs off the application, but does not close the browser (assume a Kiosk environment )

Then and a second (malicious) user approaches the terminal and then hits the back button or simply browses the history.

As a result, the malicious user is able to view content they are not authorized for.

What are my options for preventing this?

What can I do to keep the site "user friendly" and allow authenticated users to go back though history, but not unauthenticated/unauthorized ?

Some ideas I was playing with include

Cache-Control: no-cache
Last-Modified
Expires
And also Javascript to refresh the authentication for the page

But I'm unsure how these various settings will be affect a Web Browser when operating in an SSL or non SSL mode.  This gets even more complicated if a proxy is involved, hence I decided it would be wise to check in with the experts.

Use SSL
Make sure you implement session management correctly - for example the presence of correct session id checked on each page and destroyed with logout
Add cache control: no-cache, pragma: no-cache and expire: -1 headers everywhere
Make sure that forms and every sensitive variable are submitted only through POST requests and not GET (during code audits I've seen countless times pages accepting both methods without any reason)


Why are generated access tokens for APIs much longer than passwords? I'll take Twitter as an example.

On one hand, when registering on Twitter, the password must contain at least 6 characters.

On the other hand, access token to the API have about 50 characters:

(source)

I'm wondering about the security reason behind this difference in length. If the tokens are really long because it improves security, why are short passwords allowed? Please note that I'm not asking why the minimal length is not a given number like 10, 15 or 20 characters, it would still make a great difference compared to tokens.

And while this token is hard to guess because it's random and longer, I can see my own tokens by connecting to the Twitter developers website with my relatively weak password. Why create a secure random token if it's accessible with my password? I know that it's possible to activate the two-factor authentication but the access to the developers website doesn't require it.

So, given the facts that:

a token allow more or less the same operations than a logged in user though its password,
accesses to API can be brute-forced as accesses from Internet,
Twitter can choose the minimal length of a password and the length of tokens,

why are tokens so long? If from Twitter's point of view 6 characters are enough for a password, why use 50 characters for a token?

Quite simply, the token is not designed to be memorized so it can be as long as they want.  A password is limited in length to what a person can practically reliably recall after a short memorization period.  This limits it to 7-10 characters for most people.  The token is designed to be copy/pasted, just once even (since it is application specific) therefore there is absolutely no penalty to being long, and the great length allows it to be both secure and unique (i.e. the token can have enough embedded information to tie back to a specific account).

I suppose a more pointed question would be, why aren't passwords longer ;-)


Is there a single maintained source of truth for trusted Certificate Authority Root Certificates? So I notice that a lot of different products and systems seem to have their own version of CACerts or generically, a file containing a collection of trusted Certificate Authority certificates. For example the Java SDK has cacerts, Mozilla, and other browsers have their own versions. In addition I see a couple of Linux packages have their own versions. And of course there are Microsoft and Apple versions.

Is there a single maintained source of truth (ummmm Trust?) for Certificate Authority Root Certificates? Whom do you trust?

Every Root Certificate programs have different requirements for including an Authority in their root store, that is why there's no single truth, because they're all truth according to their respective root program's requirements.

The root program's requirements in all major browsers are more or less aligned with the CA/B Forum Baseline Requirements, but each root program are allowed to add more requirements, which leads to different browsers shipping with slightly different set of root certificates.

  Whom do you trust?

Trust is a complicated thing, it's not binary. The fact that I trust Mozilla's Root Certificate program for verifying certificates for web servers during my daily browsing, does not necessarily mean that I trust them for code signing of my company's internal code signing authority for software that we develop, run, and deploy. And neither does the fact that I trust my internal code signing authority for signing these software means that I trust them to certify web sites that I visit using my work computer.

If trust is really important to you, you will want to verify yourself which part of the root program's requirement matches your own requirements, and which ones of your requirements are not satisfied and for which you may need to do separate verifications.

Note that most public Certificate Authority root program are concerned about identity, rather than the ethics, competence, or even legality of the business practice of the organizations they sign for.