What was so dangerous about PGP that its creator was charged in court for it? I was reading up on the history of the PGP encryption software when I realised its creator was under criminal charges for munitions export without a license for releasing the source code of PGP.

What was so dangerous about PGP at that point in time that it was an offence under the law? I mean, PGP is just an encryption and decryption algorithm; what am I missing here?

PGP was considered dangerous because it could have allowed Soviet spies and military officers to plan the nuclear annihilation of the western world without the CIA realizing what's happening before it's too late.

Time for some history.

During World War II, the importance of cryptography for military use became apparent. Being able to crack enemy cryptography while also having cryptography systems for oneself which can not be cracked, proved to be an important military factor which could result in victory or defeat.

During the subsequent universal arms-race during the cold war, all sides were aware of this. Having the upper hand in cryptographic technology over the other side was considered a strategical factor which could turn the tide in another world-war. That meant that any knowledge-transfer of cryptography know-how from the Western to the Eastern world had to be prevented.

As a result of this doctrine, cryptographic technology was considered of military value and thus filed under Category XIII in the United States Munitions List. That meant any data storage medium which contained cryptographic software was legally considered like live ammunition when it came to moving it across borders.

From today's point of view it might seem absurd to try to contain knowledge through export restrictions designed for physical goods, but it fitted into the isolationist viewpoint of the military strategists of the cold war era. Also remember that this was the 70s, long before the internet age. This was decades before the time where you were able to obtain any software in the world via the internet through your favorite piracy website. Getting a piece of software from computer A to computer B usually meant to put it on a physical medium like a floppy disk, magnetic tape or (even earlier) punch-cards, and the movement of such physical media across borders seemed controllable (at least in theory).

Technology marched on. In the 80s, the first international computer networks emerged, and the hacker community began to flourish. The world became increasingly interconnected and soon it became apparent that containing knowledge within geographical borders was an exercise in futility. But as usual, politics and laws didn't keep up with technical innovation, so when PGP emerged in the 90s, it was still subject to cold war era laws regarding cryptography exporting. The algorithms it used were open secrets, available to anyone in the world capable of buying a modem and making long-distance phone calls. Hackers were tattooing them on their bodies to ridicule the cryptography export restrictions. But as a commercial company, PGP had to play along and find a loophole in the form of exporting their source code in printed form and re-transcribe it.

Although the restrictions on cryptographic technology have been relaxed in the past decades, some of them are still in place.


A website sends account credential field as "empty" One of Finland's largest banks, S-Pankki, seems to use some uncommon method to send the username field. At least Firefox's password manager doesn't detect the entered username and I've also experienced the same with Lastpass. Why does this happen?

Sadly the website isn't available in English--enter account credentials (you don't need to have an account, use fake data) by pressing the orange "verkkopankkiin" button (followed by clicking "kirjaudu"/Enter) if you have to test in order to answer the question.
"Käyttäjätunnus" means username, "salasana" equals password.

First off, there is the technical explanation that is already covered in the comments: The website seems to use the input type password, not plain text - hence password managers that search for a plain text/password combination fail to recognize this field.

Then there is the wider question of why this would be done.

In this case, this is a bank, which often use your account number (a somewhat sensitive information) as a login name. Using not a plain text field may be to keep (as the comments mentioned) shoulder surfers from peeking your user name.

Yet, this might as well be an attempt on compliance. There are some regulations that do prohibit saving user name/password combination as to avoid problems that might arise from saving passwords:

People tend to forget passwords more often when they do not type then regularly
Malware might extract those saved passwords when they are not handled with care

Those points are not all too valid - the first one even encourages password reuse when no password manager may be used, which is horrible.

The second point is somewhat reasonable with respect to the default setting of most browsers to save such data somewhat unprotected (e.g. without a master password for the vault).

Nonetheless, some regulators do stick to those guidelines and while there exist better ways of complying, this might very well be an attempt of doing so.


What are the real world risks of opening ports for multiplayer games? We have a multi-user enterprise training application built using the Unity game engine and are discussing the security implications of adding a Windows Defender Firewall rule globally opening an application specific port for that application on the systems where it is run. Due to the architecture of the application the set of executable paths is not known at install time so we haven't figured out a better way to whitelist just the required port on just the executables we need than globally opening the required port.

The application is run under a non-admin account and is installed with an installer that doesn't currently require any elevated privileges. It doesn't do general disk IO, it only reads its own data files and writes out logs to hard coded locations. The systems the application runs on are not on the corporate domain and are not used for any other purpose (they should not have any sensitive data stored on them).

There is some concern about the security implications of globally opening a port. It seems to me that the real world risks are quite low. We can choose a port which is not used by any other applications or services running on the machine so the only real risk would be someone figuring out a successful remote privilege escalation attack on the application itself while it was running (a risk that is somewhat inherent to a multiplayer / multiuser game-type application). I may be missing some potential security implications here however. I'm interested to hear people's thoughts on how big a security issue this really is in practice.

The risk of opening a port is that the listening application can be exploited. This means that, for instance, if a Unity zero-day is found these systems would be at risk. Only half 6 months ago a remote code execution bug was found in the Unity Editor (CVE-2017-12939). Note this affected the editor, not the games created by it. New security bugs are discovered all the time, thus any application listening through an open port could potentially be attacked.

Make sure that the port is only opened for the specific application, to prevent the port from being open for other applications that you might install in the future.

If you're paranoid and want to reduce the risk, there are a few options.

Do you need a listening port?

If you build the application in a way that only the servers are listening and the clients initiate the connections, you don't need to open a port (unless you also have an outbound firewall on those clients). This also saves you the hassle of having to forward ports manually on NAT devices in your network.

Create a minimal priviledged user account for the application

You mentionioned that your application only needs read-only rights on a few files in a specific folder. you could create a new user account on the systems you install the application on, and give it priviledges to only that folder. If you do this, make sure the application is run using that user account. This means that if an attacker exploits the application, he will have more troubles to escalate priviledges. This however takes a lot of extra work and is only for the truely paranoid.


Which Linux commands can execute user-supplied code? As explained here (https://www.helpnetsecurity.com/2014/06/27/exploiting-wildcards-on-linux/), the tar command can be used to execute arbitrary code.

Is there a list of Linux commands, preferably including commands in packages in the official distro repos, along with whether they are known to have any functionality which executes user-supplied code? Of course, such an analysis could not determine that a command is secure, just that there is not a well-published way to execute arbitrary code.

EDIT: The system has a quite a few commands whitelisted, and although there is a legitimate use for all of them (eg. kill to kill a hung VPN connection) I think there might also be some illegitimate uses.   I am not asking whether to apply the principle of least privilege, but if I am applying it effectively here.  Rather than just asking about the specific commands on my system, I decided to ask a more general question.

What is it you're trying to protect against?  You sound like you're trying to protect against malicious users deliberately trying to gain further access to the system.

In that case, I'd suggest trying to find some other way for users to accomplish the same thing, without using sudo.  Well written suid scripts that accomplish the same thing, for instance.  sudo should be limited to users you trust, and users competent enough to understand Linux commands (more below).

You should also consider the case where the users are non-malicious, but have a deadly combination of incompetence, and over-confidence.  Several years ago I gave sudo access on a development server to a developer who was non-linux savy.  Within a week she completely destroyed the linux server environment with a find -exec command she found though googling how to fix her code. She didn't understand the implications of the find -exec command, and it completely changed all the permissions on the filesystem (including setting critical system binaries to non-executable).  I rebuilt the server, talked to her about the power of the find command, and removed her sudo access.

In both cases, you could likely still use whitelisting to give you some level of protection.  The problem with this approach is that raw linux commands run as root are extremely powerful, and it's difficult to anticipate all the ways either maliciousness or incompetence could bite you. Honestly, eliminating the need for sudo in the first place is still likely the best option.


Truly Disabling Session Tickets in Windows 10 Schannel In windows 7, session tickets were disabled by disabling schannel cache, example:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000004
"MaximumCacheSize"=dword:00000000
"ServerCacheTime"=dword:00000000

Other Microsoft sources say the following in regard to Windows 10: Schannel EnableSessionTicket, value 2, disables Session Ticket TLS "Optimization" in the system.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EnableSessionTicket"=dword:00000002

Is there a difference between "Session Ticket TLS Optimization" and "Session Tickets in general?" Or is it TLS Session Tickets with OPTIMIZATION, like rtt0 or some other form of optimization?

Logically, I would assume disabling TLS session tickets would require the following entry

"EnableSessionTicket"=dword:00000000

However, this source claims setting dword:00000002, the system will revert to handling TLS sessions exactly like the sessions were negotiated in earlier Windows Server operating systems.

To disable Session Tickets, does this mean users must enable the following 3?

"EnableSessionTicket"=dword:00000002
"MaximumCacheSize"=dword:00000000
"ServerCacheTime"=dword:00000000

And finally, what does "EnableSessionTicket"=dword:00000000, and dword:000000001 do?

Thank you.

I'd recommend if possible that you use Disable-TlsSessionTicketKey from powershell instead of the global disable.

This affects the service account specified, preventing it from decrypting existing TLS session tickets and does not affect anything else. This method makes it easier to protect a specific service that we know it could represent a vulnerability, while not preventing other services from using the feature.

Otherwise, you can set

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\MaximumCacheSize to 0

and

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ServerCacheTime to 0

and by preventing any caching the ticketing feature will not work. This is sufficient to prevent it from working.
The disadvantage of this may be latency in the case of heavy TLS usage.

Note that the setting "EnableSessionTicket"=dword:00000002 does NOT disable ticketing, it disables the session ticket TLS optimization. Logically, if you'd want it disabled you could set it to "0", but as I mentioned it is not necessary if there is no caching.


Is or was it possible to register a wildcard certificate to third level subdomain? The use of a null byte in a certificate cn is very well known…

and I saw this code in a popular smtp server (who obviously thought it didn’t worth to use the gnutls or openssl for doing that kind of thing) :

static bool
does_name_match(const char * name, const char * pat) {
char * cp;
return *pat == '*'      /* possible wildcard match */
  ?    *++pat == '.'        /* starts star, dot              */
    && !strchr(++pat, '*')  /* has no more stars             */
    && strchr(pat, '.') /* and has another dot.          */
    && (cp = strchr(name, '.'))/* The name has at least one dot */
    && strcmp(++cp, pat) == 0 /* and we only compare after it. */
  :    !strchr(pat+1, '*')
    && strcmp(name, pat) == 0;
}

which will prevent the recognition of*.\0.thoughtcrime.orgor*.*\0.thoughtcrime.orgwithtip.emailwill trigger a match in the case of*.fmm.email\0.thoughtcrime.orgwithmail.fmm.email

So is it, or was it, possible to register something like*.e10000.biz\0.thoughtcrime.org (since e10000 and biz can be considered as usual words and not only subdomain)

Looking at google certificate’s, it’s now very clear…

The answer is yes of course since you can request to be a certificate authority for the domains you control…


Is image meta-data copied when taking an iPhone Screenshot? If a photo is taken using an iPhone, the image file can carry date, time and location information. If this original image is then screen shot, would this original information be copied with the screen shot

No, it will not.

Information such as time, date, author, etc. is stored as EXIF metadata. This data is kept separately from the image itself, and as such will not be retained if you take a screenshot of that image.

You may be thinking of steganography, which is the process of hiding information in another piece of information. The Wikipedia article offers an excellent introduction to the topic, along with an example of what it can do.

This can be used to hide information in the image itself, but EXIF metadata isn't stored this way.


Encrypting short data with RSA only? I have a case where I need to create recovery accounts and I want to create them so that nobody knows the password to them until/unless necessary. Hence, I thought that I would do it using RSA - when the account is created via code, it will generate a random password for it that is then also encrypted with a public key and stored for possible later use.

Since the plaintext will be short, say 160 bits with a 20 character alphanumeric password, there's no need to do RSA->AES symmetric encryption. However, that makes me wonder about the security implications:

Since an attacker could get access to the public key and encrypted password, a chosen plaintext attack would be possible to try to bruteforce the password since RSA is normally deterministic. However, if I use PKCS #1 v1.5 padding (or OAEP), that should be covered, right? Or should there be random padding (anyway) - the plaintext is limited in scope and length?

Well, you said that "RSA is normally deterministic", but that's the point: RSA encryption is normally non-deterministic. By "normally" I mean "when performed as is described in the relevant standard", namely PKCS#1. Both the old ("v1.5") and the new ("OAEP") RSA encryption methods include randomness, and that is voluntary: this is precisely to prevent exhaustive search on the plaintext.

The operation that lies at the core of RSA (the modular exponentiation) is deterministic, but don't let it fool you; RSA asymmetric encryption, just like any other decent asymmetric encryption, is randomized.

(Some people call the raw modular exponentiation "textbook RSA" as if it was an algorithm in its own right, but that's just wrong and confusing.)


web security testing - vulnerability issue I'm testing a website to find out vulnerabilities. Website is fully running on HTTPS only.

While testing, I came to know that the pdf files can be downloaded by authorized users only. This functionality is accessible after being logged-in into the application.

Suppose this is the path:

https://www.test-site.com/confarea/private/ebook.pdf

But when I'm changing the https request into http like below, I'm able to download the file directly without any restrictions.

http://www.test-site.com/confarea/private/ebook.pdf

So, according to OWASP Top 10 - 2013:

What kind of vulnerability is this? Does it belong to "A4 – Insecure Direct Object References" or "A7 – Missing Function Level Access Control"?
Does this vulnerability has any particular name?
What would be the severity and impact?

Please explain it in-depth.

The web server seems to apply different security control whether the access comes from HTTPS and from HTTP.

Most probable is that the designers thought that this file would be accessible only to HTTPS users, and missed the fact that this URL can also be served through HTTP.

In your question you refer to:

A7 – Missing Function Level Access Control: This flaw is about a mismatch between the options proposed in the web interface and the options actually accepted on the web server side, the error being to disable an option only on the interface without disabling its use on the server side. Here there no mention of web interface, and allowed user should use HTTPS link anyway, so this is not the correct topic to classify the current issue.
A4 – Insecure Direct Object References: This flaw seems to address merely internal objects access, ie. objects which should not be accessed at all. However, one may argue that this file should indeed not be accessed at all through HTTP, so from this point of view it might be a correct topic.

Otherwise, "A5 - Security Misconfiguration" may also match since this is just a setting issue, either an HTTPS file access setting wrongly affecting HTTP accesses, or a missing restriction on HTTP file accesses.

Regarding the technical impact, it gives unauthorized people access to this file. The business impact directly depends on the file's content.


How to proceed if a new hash algorithm for passwords is introduced? I have an e-mail address at a certain institution. A few days ago they sent me an e-mail (in German), which I'd like to paraphrase without revealing the institution:

  Dear Madams and Sirs,

  a new identity management system has been introduced at the ... Together with the new system, a new password guideline came into effect. Thus, it is now necessary for every user to have his current password checked by the new system.
  You will soon receive a personified e-mail with instructions on how to confirm the password via the webpage of the [name of IT department] of the ... (Web: [website of IT department] -> ... -> [confirm password])
  We point out that at no point in time we will ask you to send your login or password via e-mail or to change or confirm your password on any other webpage than https://idm... Communication with that webpage is always encrypted (https). You can check if the webpage indeed belongs to ... by clicking the lock symbol in the status bar of your browser. The fingerprint of the certificate is ...
  In case you are still unsure whether the above request has in fact been sent by the ..., please contact the help desk. (Web: [website of IT department] -> [Services] -> ...)

  Yours sincerely, ...
  (security administrator)

Now this does not look like a phishing e-mail to me, and a collegue has in fact contacted the help desk: they confirmed it was our IT department who sent the e-mail.

What I'd like to know is whether sending the above e-mail was appropriate. They told my collegue that they had to do this because of a new hash algorithm they're about to use. I understand that they can't produce the new hashes from the old ones, but I still think that doing it via such an e-mail is very strange at best: it just makes users more insecure when the next real phishing e-mail arrives. What I find particularly dubious is the direct link to https://idm... in the e-mail!

What I would have expected in such a case: The IT department just sends a request that every user changes his e-mail until this and that date. Would that be a better approach? Or was the IT departments approach better?

Update: They sent the "personified e-mail" a day later. It contained two pieces of new information:

The sentence "The password has to be changed if it doesn't confirm to the new security rules",
a date until when I'll have to confirm my password.

It is true that since good servers never store passwords, only password verification tokens (i.e. hashes), then they cannot change the hash function without the user cooperation. By requiring users to reenter their password, they are telling that they already stored passwords in an appropriate fashion (or, at least, not in an horribly weak way).

However, asking users, by email, to reenter their passwords (following instructions in a subsequent email) is very poor practice. Users should be trained never to do such things. This institution is undoing years of patient educational efforts. Moreover, there should not be "special instructions": the process of updating the hash function should be automatic and transparent upon the next login by the user. I find it quite suspicious that anything special should be done by the users at that point -- unless they are planning to enforce one of these dreaded "password policies" which will reject passwords which do not contain letters of both cases, digits, punctuation signs and two Sanskrit words from distinct sūtras.

In my opinion, the proper way to update the hash function for password hashing is to do it transparently over a long period (several months), and to simply "lock out" accounts which have not been used during the whole period. If there is a need to have users really connect in an immediate way, send an email stating that "your account has not been used in 6 months; for security reasons, it will be disabled if you don't connect within the next month, and reactivation will have to be handled through the helpdesk".

@CodesInChaos suggests "chaining" hashes, i.e. using the old hash value as the "password" for the new hash value, at least in a transitory fashion. This works and provides the security benefits of the new hash as long as all of the following hold true:

the old hash was "decent enough" (e.g. it was a MD5 on the password, not the old Unix DES-based hash which truncates passwords to eight characters);
you have a place to store the extra parameters (salt, iteration count...) for the old hash along with the parameters for the new hash (or they have the same format and can thus be shared);
you are ready to assume the CPU cost of computing both hash functions when verifying the password;
if transitioning (i.e. you want the chain hashing only up to the next login for this user), then there is a way to mark the stored hash as "transitional", so that the verifier knows that it must compute the old hash then the new hash.

So it depends on what the old function was, what the new function is, and why you change it. Chaining hashes is certainly a good idea when the previous hash is a simple, unsalted, non-iterated invocation of MD5 or SHA-1.


Is sending a string (representing a HTTP message) over SSL the same as sending a HTTPS message? I want to communicate from an embedded device that only has SSL for encryption with an intranet-server that can receive HTTPS.

Will SSL encrypted HTTP string be interpreted as HTTPS? or is there more to HTTPS than just sending a HTTP string over SSL?

HTTPS is HTTP over SSL. SSL first connects to the host, so the host name and port number are transferred as clear text. When the host responds and the challenge succeeds, your  client will encrypt the HTTP request. This is said, and by putting in mind how the communication between layers in the OSI model occurs:

As SSL acts in the Session layer (5) and HTTP  on the Application layer (7), SSL encrypts HTTP request (including the HTTP headers themselves), and since the HTTP request format (simplified) looks like follows:

You can conclude that you are referring to the same notion expressed differently.


How To Protect My Personal University Account from an SSID spoofed AP? On our campus, there are WiFi routers almost everywhere (at least inside buildings) but some areas definitely have a spottier connection, since the campus is quite large and there are many big open outside areas.

Now to connect to their WiFi, when you attempt to connect to it, it prompts you for your student username and student password (can't remember the type of connection this is off the top of my head).

What's to stop someone from walking around with a laptop acting as a router with the same name as the real routers automatically collecting my student username and password as I walk by it? If nothing really, is there something that I should be doing so that my username and password isn't collected, besides simply not using the provided WiFi?

With Captive Portal connections, about the only thing you can do is to ensure that the captive portal site is accessed only via HTTPS and make sure that the certificate is correct. If you get any kind of a certificate warning, don't connect.

You also need to take some care not to have non-secured network connections running at any time. Make sure any email clients are connecting securely and remember anything that connects without encryption, even once connected to Wi-Fi is potentially vulnerable.

You can also assume that something is always monitoring your traffic even with a valid connection. Stay clean. Don't connect to anything daft.

If you need extra protection for some reason, consider connecting via a mobile phone if you have sufficient data.


On the ability to reverse engineer the Instagram Private API I came across these blog posts where a man was able to extract the Instagram private signature key from the Android app:
http://mokhdzanifaeq.github.io/extracting-instagram-signature-key/

Which could then be used for the purpose of exploiting Instagram's private API, like so: https://gist.github.com/will3942/8113903#file-app-rb

A few personal questions arose out of this:

Is there anything else the Instagram security engineers could have done to prevent this from happening?  I assume they are extremely talented software engineers, but does having a user in possession of an app, in this case in the form of an android .apk, make it always inherently easier/always possible for people to discover secret keys?
Are web apps inherently more secure than mobile apps?  Let's say that the Instagram web app is identical to their mobile app.  Would it still be possible for someone to extract the web app secret keys, or is this much more difficult, if not impossible, to do because the user will never be in possession of the full source code of the web app.

Yes, once you release an application, you have no control over what people do with it. You can obfuscate or pre-process code to make it harder to find things out, but by definition, it needs to be executable and accessible to the underlying processor. Given enough time and effort, someone can always find out anything that is embedded in the application. This applies to any type of application - mobile app, desktop app, console app. If all else fails, a really determined attacker could emulate the processor and dump out what happens.

No, but the attack methods change. Taking the Instagram example, if you have a web app, communications can be sent over an encrypted channel, but they might not be able to control the source of communications. It would be difficult to distinguish between the legitimate app and a third party one. For some businesses, this is important (for example, if they show adverts in their official app). On the other hand, with a mobile app, it would be possible to provide, for example, certificate verification, where the server and client mutually verify each other. In this case, it would be possible to remove a compromised certificate on the server side, although this might cut off users who haven't updated their apps.
In the first case, attacks would concentrate on identifying valid calls to the backend system, and then attempting to abuse that. In the second case, attacks would initially try to extract the certificate, but in that process would probably find the calls.


what is the difference between dll hooking and dll injection I am confused and would like to know the difference between  DLL injection and DLL hooking? I am familiar with its use in malware and I know that key-loggers use it. I also know that SetWindowsHooKEX is used in DLL hooking.

Hooking uses an operating system feature to monitor events sent to the process, like low level keyboard and mouse messages. Applications can utilize a targeted or global hook in order to keylog (malevolent) or listen for keystrokes in order to perform value adding functionality such as executing macros or other hotkey functionality. (benevolent)

DLL injection is what it sounds like, a dynamic linked library is injected into the target process by forcing the process to load the DLL. Once loaded, the injected DLL can act sort of like an API that can be accessed externally from the process (think backdoor API), and can interact with the public internals of the process that would otherwise be impossible.

DLL injection is mostly use benevolently by software debuggers and accessibility software for the disabled. However it is also used for cheating in single-player videogames through things like cheat-engine and trainers.

A trainer utilizes both of these techniques. The application that is loaded (the trainer) hooks the target application and listens for keystrokes associated with hotkey functionality. Usually at the same time it will DLL inject the application with their backdoor API.
The trainer then listens for keystrokes that are associated with hotkey functionality, and when that keystroke event is detected, executes the associated functionality through the backdoor API.

As far as security is concerned, you do not want any non-trusted software doing either of these. You should be very careful with who you trust, and that is why non-reputable trainers are so dangerous to install and use. Both of these techniques require elevated permissions from the OS, which gives them access to other high-level OS features that you would never want non-reputable software to have.

Keep in mind when using these applications can listen to everything when loaded. Just because they say they inject "ApplicationA" doesn't mean they aren't also injecting your web browsers and password managers as well.

Use at your own risk.


Government / State cyberwarfare organizations I am working on some research regarding advanced persistent threats.  Within this effort, discussion of cyber-warfare started.  Looking further into the subject, I have found a plethora of links regarding the US and China when it comes to state sponsored initiatives when it comes to offensive cyber warfare but virtually nothing regarding other states.

Though I would be more than happy for more information regarding any part of this topic, my question is this... What countries currently have cyber security procedures/policies/organizations which address offensive security measures?

Granted there is a bunch of speculation regarding Russia and North Korea, and some information about Israel/Iran out there.  I am looking for actual state sponsored activities, not just speculation of them.

This is not specifically IT Security practice, but it is very related, so I felt that it was reliant to this StackExchange.

There are no actual citations in the article, but according to the Guardian the UK is developing a cyber-weapons program.  From the article (emphasis added):

  Military to gain a new range of offensive options to defend critical installations around the country from cyber attacks

The article does directly quote a few high level officials (including one member of Parliament), so it should be fairly easy to find out if it's been refuted.


Is sending plain passwords over SSL as part of a password update process bad? The Web application I'm working on is 100% SSL secured (or rather TLS as it is called today...). The application recently has been audited by a security company. I mostly agree with their results but there was one thing that led to great debates:

As part of the password change process for users, the user has to provide the old password as well as the new one two times—nothing unusual. In addition to that the new password has to conform to a password policy (minimum length, yadda yadda).

The application is realized with Vaadin which uses small AJAX messages to update the UI. The whole logic of the application lives on the server. This means that all validation of the password change form happens on the server. In order to validate the form, both the old password as well as the two new passwords (which should match of course) have to be sent to the server. If there is anything wrong (old password is wrong, new passwords don't match, new password doesn't conform to the password policy), the user gets an error. Unfortunately as part of the syncing process Vaadin sends all form data back to the client again—including old and new passwords.

Since all this happens over SSL I never thought twice about it but the security company saw this as a security risk of the highest severity. Note that the issue in the eyes of the security company was not that the data is sent to the server but that the server included the data in its response in case validation failed. So our current solution is to empty all fields if validation fails. This leads to poor user experience as the user has to fill in three text fields again and again if for example the passwords repeatedly don't match the password policy.

Am I being naïve in thinking this is way over the top? I mean, if an attacker breaks the encryption, they have access to the whole traffic anyway.

edit: Regarding shoulder surfing I want to make clear that no password is ever echoed back to the user. All input fields are proper password fields that only show placeholders but no actual characters.

Actually, I'd argue that it's better UX to clear the fields. Assuming the password fields are full of asterisks, the user is going to delete the whole field anyway when they retype their password.

In addition, you're opening yourself up to a new security risk. There are possibilities for XSS, shoulder surfing, and also any time you send passwords anywhere you've increased your risk in general.

I've never visited a site that's kept the password fields filled had I entered something incorrect. The only field that has been filled was the email field, and possibly address/phone number.

You always have to assume the worst, and if you can plug a hole do so. I don't think the security auditor is over the top, especially since this is an easy fix for a really non-existent UX issue -- and if you're sending back their passwords and showing them without changing each character to an asterisk, then you definitely have a security issue. The only time somebody should see a password they enter is if they select an option to allow them to see it temporarily.


Why is GSM still used? GSMs vulnerabilities have been known a long time now. UMTS was supposed to fix those problems. Why is GSM still used?

This started as a comment reply to @user10008 but got too long...

Even after the towers are all upgraded, the carriers can't immediately switch off 2g service for a number of reasons.  The biggest issue there is that not everyone upgrades their phone frequently; in particular this is true of people who use it as just-a-phone or an emergency-use-only-phone.

There are also commercial/industrial embedded systems that use the cellular network to report home.  Low bandwidth devices like monitoring systems, ATMs, or credit card readers have no need for high speed data and no reason for the owners to upgrade frequently. AFAIK they typically have SLAs with carriers to guarantee longer term operation than the standard 2 year consumer contract.

Regulatory issues can also be involved.  In the US, you're not allowed to turn off a voice network without giving customers free new phones without contract extensions.  As a result, the major US carriers have scheduled 2017-21 sunset dates for 2g service to give as much time as possible for the long tail to upgrade on their own.  That said, the carriers probably will refarm all but a tiny sliver of their 2g spectrum to 4g (5g?) prior to the shutdown to maximize utilization rates.  When the finally do force the issue and shut down their 2g network, they probably will end up having significant numbers of customers who were coasting month to month due to apathy shop around and decide to change carriers.

When Sprint shutdown the iDEN (2g with no upgrade path) network they inherited from the Nextel acquisition; they suffered heavy customer attrition in the final months from people deciding to switch carriers instead of taking a free replacement.  IIRC the loss rate for the final few months was >50% of the remainder and several hundred thousand customers in total.


Why are Android permissions granted in groups? The Android documentation on Permission Groups states that

  If an app requests a dangerous permission listed in its manifest, and the app already has another dangerous permission in the same permission group, the system immediately grants the permission without any interaction with the user. For example, if an app had previously requested and been granted the READ_CONTACTS permission, and it then requests WRITE_CONTACTS, the system immediately grants that permission.

Isn't this a security risk? Reading contacts so the app lets me share something with friends is less risky than altering existing contacts, which can be maliciously used, for example, to change every contact's email address to something resembling the original email, but actually leading to the attacker's account, which can continue forwarding the email exchange, unbeknownst to both parties.

The documentation emphasizes the point farther below:

  Once again, the system just tells the user what permission groups the app needs, not the individual permissions

The PHONE group includes CALL_PHONE and also READ_CALL_LOG.

Again, a Yelp-like app should be allowed to call a business, or an ordering app can legitimately place a call to the delivery person, but that means the app can also silently read the user's private call logs and send them to whatever adware is bundled with it, since INTERNET is a normal permission that doesn't require user consent. Call logs to certain numbers can be used as basis for blackmailing the user, or (probably more commonly) can serve as very valuable information for advertisers to figure out the user's demographic profile and social network.

Various reports have shown that a staggering number of apps phone home with data the user did not expect. Why then are Android permissions so coarse?

The user's convenience (i.e. not bugging the user too much, in Android M's runtime permissions system) seems like a weak reason. Legit apps without a reason to read the call log, won't ask for the permission, so all of the choices below will only ask the user once, but have different security results:

"Can this app make a phone call" (individual permission)
"Can this app access the phone, redirect outgoing calls (!), and read your contacts list" (current group permission with accurate wording, but unnecessarily scary as most apps will only make calls)
"Allow [this app] to make and manage phone calls" (wording for group permission in Android M, unnecessarily vague)

Same for CALENDAR - the write-only permission to create events is relatively innocuous, but reading the user's private events far less so. Etc.

Are there good reasons why permissions don't need to be more granular?

They don't want to scare users from using apps - if an app needs to use the phonecall ability it will probably need some more permissions for regular use (getting too much permissions requests from an app will concern users).
So to compensate - they put the permissions in groups.

This also effect the usability of the OS - the overall UX is better with less permissions requests:
If you look at what is written in developer.android.com about providing explanation for permissions:

  Keep in mind that you don't want to overwhelm the user with explanations; if you provide too many explanations, the user might find the app frustrating and remove it.

In paraphrase: they don't want to overwhelm the user with permissions requests  - and it also effects the OS ability to explain the permission riskiness to the user: "access contact" instead of read/write contacts and get accounts. Not every user will understand what is SIP - but every one knows what is a phone call.


Is a VPN the only way to protect against rogue Wifi access points MITM attacks? Given that it's very easy set up a rogue access point and MITM that connection, is a VPN to a trusted host the only real way to secure my browsing and other TCP/UDP actions?

This question relates to the recent FBI and IC3 announcement regarding hotel Wifi connections:

  The FBI today warned travelers there has been an uptick in malicious
  software infecting laptops and other devices linked to hotel Internet
  connections. The FBI wasn't specific about any particular hotel chain,
  nor the software involved but stated: "Recent analysis from the FBI
  and other government agencies demonstrates that malicious actors are
  targeting travelers abroad through pop-up windows while they are
  establishing an Internet connection in their hotel rooms.

  The FBI recommends that all government, private industry, and academic
  personnel who travel abroad take extra caution before updating
  software products through their hotel Internet connection. Checking
  the author or digital certificate of any prompted update to see if it
  corresponds to the software vendor may reveal an attempted attack. The
  FBI also recommends that travelers perform software updates on laptops
  immediately before traveling, and that they download software updates
  directly from the software vendor's website if updates are necessary
  while abroad."

  The FBI said typically travelers attempting to set up a hotel room
  Internet connection were presented with a pop-up window notifying the
  user to update a widely used software product. If the user clicked to
  accept and install the update, malicious software was installed on the
  laptop. The pop-up window appeared to be offering a routine update to
  a legitimate software product for which updates are frequently
  available.

Connecting to a WiFi hotspot is no worse than connecting to the Internet in general. The error would be to assume that local communications (between two machines which are bound to the same hotspot) would benefit from protection from eavesdroppers. It is only in that sense that WiFi is "weak": it does not offer the kind of physical protection that we took for granted with wired ethernet (and, even then, thinking of wired ethernet as protected is a bit of wishful thinking).

The most glaring targets are local file sharing and printer access; these are features commonly activated in enterprise and home network, and for which some level of protection is clearly needed. But Web surfing ? No, nothing special with WiFi here. Regardless of WiFi, the Internet is a harsh place, and HTTPS will protect you (if you do not disregard the certificate warnings, of course).


How do I report a security vulnerability about a trusted certificate authority? I stumbled across a huge security vulnerability in a Certificate Authority that is trusted by all modern browsers and computers.

Specifically, I am able to get a valid signed certificate for a domain I don't own. If I had the means to become a Man In The Middle, I would be able to present a perfectly valid ssl certificate.

This vulnerability required no SQL injections or coding on my part. I quite figuratively stumbled across it.

What is the proper way to report this? I want to be ethical and report it to the offending CA, but I also don't want them to simply fix the vulnerability and then sweep everything under the rug. This problem seems to have been there a while, and I'm simply not smart enough to be the only one capable of finding it.

I'm concerned that solely contacting the CA will result in a panic on their part, and they, fearing a DigiNotar-like incident, will do anything to keep the public from finding out.

Am I allowed to also contact some major players, such as other certificate authorities or other sites such as CloudFlare or Google? (I know CloudFlare was given a heads-up about HeartBleed before the public announcement went out.)

Note: I'm posting under a psuedonym account to (try to) remain anonymous for now.

Edit: This question is related to another question, but I feel this vulnerability falls outside the scope of that question. This could affect essentially the entire internet (ie everyone online is a customer), and my question explicitly states that simply contacting the 'developer' (the accepted answer for the linked question) doesn't seem like the best first step to me.

Edit 2: I've gotten in contact with some people, and they've advised me to avoid talking further on this forum (sorry guys!). I'll update this question later, after the vulnerability has been fully fixed and any incorrect certificates revoked.

Edit 3: The details are out. I've posted more information on my personal site about the specifics of the vulnerability. The story is still ongoing, and you can read the discussion between Mozilla, Google, and the CA WoSign.

Edit 4: As promised, I'm updating with a link to an article written by Ars Technica regarding this and other incidents involving WoSign. Looks like WoSign and StartCom (now owned by the same company) may be in serious danger of root revocation.

It sounds like your issue is that this vulnerability is bigger than you know what to do with.

The rules of responsible disclosure, as decribed here, say that you should contact the vendor and negotiate a period of time - between 1 week and 6 months, depending on the depth of the changes required - in which they can implement a patch, revoke and re-issue certificates, publish security bulletins, etc, before you go public with your findings. The intention is that at the end of the negotiated period you get your public recognition, but your going public can't do any more harm - if the vendor has done their job properly.

If figuring out how to contact them / negotiate a Responsible Disclosure period, go public with your results at the end, etc, is too big for you, or you don't know how to get started, then I suggest contacting and partnering with a well-known security researcher who already has established publication channels. Find a big name who has already published similar vulnerabilities and call them up! It sounds like you won't have any problem getting their attention.

Also congratulations! I look forward to seeing your name on a paper in 6 months!


PCI DSS - mask PAN and log individual access to PAN How do you re-conciliate two PCI DSS requirements in applications:
3.3 Mask PAN when displayed (the first six and last four digits are the maximum
number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.
10.2.1 Log all individual user accesses to cardholder data

To be more specific, application search screen (based on users search) lists multiple  results in table format where among others is PAN, cardholder name, merchant ID etc. We always mask PAN on such result table and if user has business need to see the PAN, he/she can click on the masked PAN in order to see full PAN. This click triggers logging mechanism and we can see which user accessed certain PAN (therefore, complying with PCI DSS req 10.2.1). Of course, we get complaints from users, that this is not user friendly because they cannot immediately identify PAN which they require.

My questions would be - what would be your approach to this? Any suggestions to improve?

I think you have a good approach. I find it interesting that users would complain about not being able to immediately identify card numbers when they can view the first six AND last four in your results table--it is unlikely that there would be two results with the same masked number.

The way you currently have it implemented is good because it has very detailed logging of access to cardholder data. However, if the user has a business need to be able to view any of the card numbers on file (the ones presented in the masked results table) there is no stopping you from displaying the full card numbers in the results table instead of the masked results.

I agree that the wording on the requirement is a little confusing:

  Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN

My rewording of the requirement would be this:

  Mask PAN when displayed for user without a business need to see the full PAN

If the user has a business need, there is no restrictions on how much of the data you show them at a time. The only difficulty for you would be implementing logging on which card numbers actually got displayed to the user. While this isn't as straight forward as the single card approach, there are a number of technical solutions you can use to address it either in the database or the application.


I can't access websites that use HTTPS, instead getting the message "your connection is not private"! I found myself suddenly unable to access websites that use HTTPS, so I contacted my service provider, and they asked me to install a certificate in the Trusted Root Certificate Authorities store. But something isn't right: installing a certificate on every device connected to the same network just to be able to access websites that use HTTPS is just weird! How can I be sure that this certificate is issued by a trusted CA?

When I tried to install it, I got the following message:

  Warning: If you install this root certificate, Windows will automatically trust any certificate issued by this CA. Installing a certificate with an unconfirmed thumbprint is a security risk. If you click "Yes" you acknowledge this risk.

Here is the certificate information:

Version: V3
Serial num: 00 f8 ab 36 f3 84 31 05 39
Signature algo: sha1RSA
Signature hash algo: sha1
Issuer: ISSA, Internet, Internet, Beirut, Beirut, LB
Subject: ISSA, Internet, Internet, Beirut, Beirut, LB
Public Key: RSA (1024 bits)

It's valid until 2019.

And by the way, I'm in Lebanon.

I contacted my ISP again and they told me that they're using some kind of an accelerator to enhance the speed, and it needs authentication, so they chose to use a certificate instead of making the user enter a username and password every time they wants to access websites that use HTTPS. And they suggested that if I'm not okay with that, they would put me in a new pool. So what should I do?

Whilst I don't know the specifics of your ISP, I would say that it's likely that what they're doing here is intercepting all traffic you send over the Internet. In order to do that (without you getting error messages whenever you visit an HTTPS encrypted site), they would need to install a root certificate, which is what you mention in your post.

They need to do this as what this kind of interception usually entails is creating their own certificate for each site you visit.  so for example if you visit https://www.amazon.com they need to have a certificate that your browser considers valid for that connection (which is one issued by a trusted Certificate Authority, either one provided with the browser or one you manually install).

From your perspective, the problem here is it means that they can see all your Internet traffic including usernames/passwords/credit card details.  So if they want to, they can look at that information.  Also if they have a security breach it's possible that other people might get access to that information.  In addition, they may also gain access to any account that you access over this Internet connection (e.g., email accounts).  Finally, installing this root certificate allows them to modify your Internet traffic without detection.

What I would recommend is that you query with them exactly why they need to see the details of your encrypted traffic (e.g., is this a legal requirement for your country) and if you're not 100% satisfied with the response, get a new ISP.  Another possibility is to use a VPN and tunnel all your traffic through the VPN.  If you are not happy with your ISP gaining this access to your HTTPS connections, do not install the root certificate they provided you.


Credit card fraud preventions Ok lets say some one have clone my debit card here in Greece all debit cards have and stripe and chip and lets say in a way he knows my pin and all my information and he put the info on a blank card can he take my money? i repeate here in greece all banks have chip

This should probably be closed as a duplicate, but given the sheer volume of duplicates, I figured I'd list them in an answer instead of a comment (to make them fit, and for readability) for posterity:

Bank cards - chips vs mag stripe security
Why are chips safer than magnetic stripes?
Why does my debit card have a stripe AND a chip?
What are the problems that Chip card technology solve? and what are the problems EMV solve? …
Why EMV cards cannot be cloned?

These, and many more interesting posts, can be found using the search interface in the upper right hand corner.


separate log for windows Hi I am trying to find a comprehensive all-event logging for windows 10. This doesn't have to be a product, it can be a script. I don't care.

Problem: My pc is being attacked continuously but the logs are being altered and I need to get some additional information about what is being changed.

Is there an open source type software or a script I can use to continuously monitor file changes independently of event log?

What I need:
Not an event log rehashed but an independent timestamped log of any file changes on my pc.

Many thanks

Based on experience, I'd say that it is not that likely that you are being continuously attacked, check for hardware errors, especially disk corruption causing odd errors before assuming an attack as that is far more likely.

However, to answer the actual question, one way would be to install a Syslog Agent so that Windows events are passed out to a syslog server. You will need to configure such a server of course but that is easily done using a Linux computer which could be a simple single-board computer such as a Raspberry Pi.

Solar Winds provide a simple syslog agent for free. THere are other options of course.


Why does Telegram not use end-to-end encryption? Signal and Telegram are both mobile applications that "try" to ensure secure chats.

Signal uses end-to-end encryption, Telegram does this as well (in 'secret chats') but it does not use end-to-end encryption in group chats.

How come? Is it difficult to implement?

As far as guessing anyones motivation for not doing something goes:

Yes, especially group chat is not easy to implement as secure key sharing in groups is quite a challenge when you consider what happens if anyone leaves the group for example.

Threema does (claim to) securely encrypt group chats, as does Tox. As Tox is open source, you may want to have a look there. Given: their mobile apps are in beta right now (at least for iOS).


How to determine the size of payloads available in MetaSploit I've noticed that there are a lot of different payloads to choose from in MetaSploit, and the choice (assuming there's enough room in the target) usually depends on what you're trying to do.

However, from what I understand the payloads vary in size greatly.  How can I determine the size of each payload so that I'll know if they will fit in the exploit?  For example, how much room would I need for a bind_tcp v. reverse_tcp?  Is meterpreter generally smaller than a bind shell?

Is there a way to determine the typical size of the MetaSploit generated payloads for a specific platform?

The msfvenom -s or generate command is useful for individual payload sizes. Sometimes you will want to know all the payloads within a certain payload size constraint. For example if you are developing an exploit, you know you have limited space to carry a payload of say 100 bytes and you want to know all the payloads that are less than or equal to 100 bytes, you can use payload_length.rb tool provided inside the tools/modules/ directory.
root@kali:/opt/metasploit-framework/tools/modules# ./payload_lengths.rb
The above command will show you size of every payload. If you want to restrict it within a certain size limit, you can always use the handy awk Linux utility:
root@kali:/opt/metasploit-framework/tools/modules# ./payload_length.rb | awk ' $2<=100'
This command is going to tell you every payload in the Metasploit framework having a size less than or equal to 100 bytes.

PS: The question has been answered but it is always good to know more than one way to do a certain task!


Is this login flow via an authenticated email account safe? I want to have users log in by entering an email, and then proving that they control that email. I only care that they do control the email, and so want to avoid add another password to the process if I can safely defer to the security guarding access of an email sent to that email account (to cut out a class of attack, I don't care about fundamentally trustworthy parties who can access the email legitimately, such as IT people at an organisation).

I've given it some thought and have come up with the following scheme. There are a lot of answers on here that give me pieces of information about the parts, but I was wondering if this specific scheme, in its entirety, is enough for me not to have to use my own password system on top of an email verification system, to avoid illegitimate third parties logging in under an email address they aren't supposed to be able to access.

submit the email address john@example.com
generate a random token e.g. 'first-token' (just pretend that's random!), with an expiry of say 2 minutes (configurable, just some shortish length of time)
send an email to john@example.com, containing a link to fire a GET over https to a login endpoint with the email address and 'first-token' as query params
the first time the login endpoint is hit with 'first-token' and 'john@example.com' whilst 'first-token' is still not expired, another token 'second-token' is generated and sent back. 'second-token' then becomes the longer-lasting access token for john@example.com, with some longer expiry (days, perhaps)
if the login endpoint is hit with 'first-token' and 'john@example.com' after 'first-token' is expired, an error is returned

So, assuming the user has their email account secured with a password that's hard to crack/socially engineer out and all the rest - how secure is this login scheme?

My immediate thought is that, as I've heard email is unsafe and can be intercepted as plaintext on the wire, this isn't secure at all. However I don't understand very well how big a problem this is - can emails sent to an account be targeted for interception without knowing the specific servers the email will pass through? How likely or even feasible is it for a specific email to be targeted, intercepted and read if you're not, for example, part of the organisation whose email server will eventually receive the email?

And, if it is unsafe, then doesn't that effectively mean most 'forgot password? I'll send you a rest link via email' flows on the internet are vulnerable to attack, as they all use something very similar, or even weaker, than the scheme above. I'm just talking about making this back door the front door - but either way the door's going to exist, right? Which leads me to believe that this scheme could be considered secure in practice?

I've thought about potential security holes in this scheme as far as my knowledge on the subject will allow - I'd really appreciate some help from the experts!

A similar question was posted recently: Is this password-less auth flow secure?

My answer - in short - was, don't do it (creating a new "security protocols" requires a lot of knowledge, effort and QA and apart from that the combination of mail, get-parameters and so on sounds pretty error-prone).

To the question "how secure is mail":

The problem is, both sending mails (via smtp) and receiving mails (via pop3) are unencrypted. It's exactly the same thing as using http for web traffic: a man in the middle (mitm) can read and compromise everything.

The question is, how big is the risk of being a victim of an mitm-attack? This depends heavily on the scenario. Are you often connected to a public wifi? Then chances are good that there might be a hacker or just a troll in the network. Are you mostly connected to a switched and properly configured private lan? In this case, it's harder for an attacker to compromise the network and sniff the traffic. How responsible is your internet behaviour in generall in terms of "accidentally" download a malware? And so on


How much of the system is secure boot going to cover? Background: We're developing for a Debian 9.8 system on an x86, but most of us here are more used to dealing with embedded devices.

according to wikipedia, secure boot can "secure the boot process by preventing the loading of drivers or OS loaders that are not signed with an acceptable digital signature". I take this to mean that kernel-level code is protected, but that user-level code is not.

I am having some terminology confusion with my boss, who is under the impression that Secure Boot can protect the entire system. I believe that Secure Boot can secure the entire system only when the computer-in-question is an embedded device (you will never receive software updates, therefore you can group all the executable stuff together and sign that). If the device is your typical PC, secure boot cannot practically keep it secure (your PC is getting software updates all the time, meaning that an executable block would be changing all the time, meaning that you'd have to recalculate/re-sign the entire block with each update).

Am I right, or is he? Is there an easy way to extend the protections of Secure Boot to our custom user-level software? Is there something similar to secure boot that I should be looking at to secure user-level software?

Your boss is mistaken I'm afraid. Here's how it works in Windows

Secure boot secures the bootloader
Trusted boot then takes over to load the kernel
ELAM takes over to load the drivers
Measured boot finishes off the process

So each stage secures the next one, each of which is performing more complex actions, which makes sense, you want anything security related to be as minimal as possible to make it easy to reason about. Once you are past the boot process, Windows Defender is the main mechanism for protection.

This is how it works when your PC is getting software updates all the time. But all the layers are required to protect the entire operating system as your boss wants.

I am pretty familiar with Debian but I'm not aware that it can do layering like this. I protect Debian systems in userspace with AppArmor.


Does it make sense that OCSP returns state for the signer CA itself I have seen an implementation that in signature verification time searches for OCSP responses signed by the CA validating the status of the CA itself, so my question is if somewhere (maybe RFC2560) says that you can revoke a CA and sign the OCSP response with the same revoked key?? does it make sense?

No where in the standards that I can recall (I contributed to 2560 and am an author to 5019) does it say you can not serve responses for yourself, that said as you point out doing so is useless since you cant trust the response in that scenario.

Are you sure that is what you are seeing though; remember that OCSP "good" doesnt mean issued it means "not revoked".

If you ask an out of scope question to a responder you may get back "good" even if the certificate was never issued. One theory as to why you are seeing what you describe  is you are asking the ocsp responder for the issuing ca using a test tool even though no client should ever ask that question.

Also in theory in this case you would expect the issuing ca certificate itself to contain an aia:ocsp:url reference but to a different ocsp responder.

Anyhow, what you are seeing is not right as you point out I hope it is a problem with the test if not I would notify the operator of the responder to check its rfc compliance and interoperability as there are likely other issues too if this is the case.


Is it standard practice to hide where links point in a legitimate email? Someone in our family recently requested a password change for a website (Costco). Soon after requesting, they received an email with the standard "click the link below to reset", followed by a link.
They noticed that the email looked a little sketchy, so they had me look at it (after they had already gone through with the reset). I found that the link they clicked had the text:
https://www.costco.ca/ResetForgotPassword?token=[a token here]

But, when mousing over it, it showed the following (abbreviated) link:
http://email-tracking.infobip.com/tracking/1/click/[a different token here]

So the email was intentionally hiding where the link went.
To me, as someone who's trying to be security minded as I enter the field, this raised some red flags. I can think of three possibilities:

Since it was the legitimate Costco website (as far as I can tell) that initiated the request, they're deferring password resets to a third-party, and ironically trying to make the email appear more legitimate by masking the link (since http://email-tracking.infobip.com looks sketchy).

The website had been compromised, and they were phishing for email/password combinations, or potentially the ability to buy things on a victim's behalf.

Our/a DNS server is compromised and the website is illegitimate, for the same reasons as above.

Is it at all common practice for companies to hide legitimate links? I'm asking because this has always struck me as the kind of thing that I should be on the lookout for when assessing the legitimacy of an email, and this kind of throws a wrench in that thought-process.

Yes and No.
The intent of this feature isn't to hide where the URL is pointing to, but to track clickthrough rate. Usually, links in e-mails are sent out for marketing purposes - 70% off for Black Friday, click >>>HERE<<< - that kind of stuff. And of course, the marketing department wants to know how high the clickthrough rate is.
Of course, the store could do that themselves, but it's much easier to just outsource it and have a nice, colorful panel that shows a neat graph, than something the IT department developed internally.
As for why the password reset link is sent this way is probably due to a misconfiguration. I am not familiar with the product InfoBip offers, but I assume somewhere in the settings, there is a checkbox like "Track all links" that results in all links sent out to customers being replaced by "trackable" links as described above.
To summarize, the point isn't to hide where the link is going, but to provide the company with a way to check clickthrough rate. The fact that this is done to a password-reset link is most likely an oversight.


Are interactive Flash (SWF) ad banners a security threat? Many times you have seen banners (Flash ads) on websites, where, when you move your mouse over the banner (without clicking it), you see how an animation in the banner starts moving toward your mouse position...

That means that the Flash banner is interactive, without asking our permission. Is there any security threat? E.g. to read not only mouse position, but also other browsers parameters such as cookies?

I don't see any special danger in the behavior you describe. Acting based on mouse over events instead of only clicking without specifically asking for permission is a common practice not only for ads and not only for flash. For example it is used to show detailed information when hovering over a tag on a question on this site.

Apart from that flash is known to be a security risk by itself and ads are too considered risky because of malvertising. You might reduce this risk by blocking flash and ads.


Whats the point in setting up an open proxy? Decided to have a look at a list of "open" proxies. I've noticed that a good deal of these proxies are on residential IPs.
One of the IPs, 68.188.59.198, is owned by Charter Communications and looks to be the IP of someone's house. It looks to have a few other random ports open, such as a VPN, telnet, and an additional HTTP port.
So, whats the point of setting one of these up on a home network? These proxies tend to be used by attackers to mask their true identities, and likley attract a lot of malicious traffic. Do they serve as honeypots for criminals? It seems to me that the only result of setting one of these up would be a knock from the police or an ISP.

Most of the time, this would be a misconfiguration, and those residential users are probably not aware until someone (their ISP) tips them off. Open proxies often tend to be short-lived, because they were not meant to be in the first place.
Even assuming the open proxy is not the result of somebody experimenting with software without the proper skills - people usually don't have security in mind when
plugging in a router, a NAS, an IP camera or some Internet-enabled appliance. But many of those devices are shipped with a default password, or no password, lax configuration rules, and may expose a number services to the Internet at large. But people just don't realize the stuff they are exposing unwittingly.


What's the inverse of sandbox security pattern? I've been reading about the definition of the sandbox pattern and reading one answer given here. In the idea of a real world sandbox, it wasn't made only to prevent the children from leaving it, but also to prevent unwanted visitors from entering it.

What is the name of the pattern for this second situation? Where the software runs in a controlled space to prevent outsiders from interfering.

This "preventing outsiders from interfering" is achieved by sandboxing the outsiders, too. When everyone can't leave their sandbox, no one can enter their neighbour's sandbox. Ideally, the code that maintains the sandboxes is as lean as possible, to reduce the number of "outsiders that can interfere" as much as possible.


Malicious packet that attacks packet sniffers? Is it possible to crash a packet sniffer through a specially-formed packet to stop website administrators from tracking down the source? If it is possible, has it been done before? Or is it just not an effective method of attack that nobody tried to do so?

I know that a huge amount of packets can crash a packet sniffer, but that won't stop a determined administrator from finding the first packet from the attack.

You have to know what software the administrators are using to sniff the packets, additionally you have to know a vulnerability that is capable of crashing the application.

If these requirements apply, the answer to your question is yes.

For reference, take a look at past wireshark vulnerabilitys:
https://www.cvedetails.com/vulnerability-list/vendor_id-4861/cvssscoremin-9/cvssscoremax-/Wireshark.html


Isolate Raspberry Pi Server I am thinking about using a raspberry pi, or some other SBC, to open a simple node.js based web server and a ssh server. I know that when opening ports there are always security vulnerabilities created. While I don't care too much about people getting into my SBC I was wondering if opening a port would also make other computers on the same network insecure.

If so, is there a way to 'isolate' the SBC from the other computers on my network?

Whenever you open up a port for inbound traffic, you are adding some risk to the network. Note that you said "insecure" but the truth is that you need to think about levels of risk. There is no such thing as a "Secure" computer, especially one connected to the Internet. You simply need to make breaking into it too hard to be bothered with. You should also try to limit the damage someone can do if they do break in which is really what you are asking when you talk about "isolation".

The risk is obviously greatly multiplied if you allow an attacker to gain a foothold on any computer, even an SBA. This is particularly true of a home network where you typically have no segmentation of the LAN. So you should and MUST care about the SBA in that situation. Thankfully, most SBA's run pretty standard Linux installations and so can be configured with the same level of security as something like a VPS.

Can you do anything?

Maybe. It rather depends on what equipment you have available or what you are prepared to install and configure. An increasing number of home/small-office routers are capable of creating a DMZ which isolates one or more machines on their own network segment. Alternatively, you can create a really strong DMZ by chaining 2 routers with your inner router carrying your WiFi and other computers and the external one connected not only to the inner router but also to your semi-protected SBA.

Also make sure that any user accounts on the Pi have no relation to user accounts on any other device and that the Pi does not need to connect to anything on your inner network. If you need comms to the Pi - which surely you will - they should be "pushed" to the Pi and not from the Pi to another device.


Sharing credentials based on the network profile Is there a way to share logins/passwords with a number of individuals, basing on their public network profile?

Example: a number of people working together in the office should have access credentials to some publicly available webpages. This should be only possible in the office. These credentials can change quite often.

A some kind of password manager would be perfect here, I guess.

In general, you never want to give multiple people access to the same account.

Here's an example of why: if someone does something they're not supposed to such as delete data, overwrite information, etc., no one knows who it is and that is a problem within a company. Each person should be liable for their actions, so having individual accounts is the way to go for this. Just create 1 account per person and put them into the same "group". Then assign permissions for that group, allowing all members of the group access to whatever webpages you would like.

Edit:

More regarding why shared accounts aren't a good idea:

Password changes for security reasons do happen, and someone would have to administer those and then communicate the new password to each user. I don't recommend this as there is never a secure way to tell someone a password. Also who will perform the above actions? A system admin should not be spending time administering this, and one of the users shouldn't do this because it could be similar to one of their personal passwords, thereby putting their emails/facebook/other sites accounts potentially at risk.
Also with people sharing a common password, there's greater risk of someone leaking the password (intentionally or non-intentially).


Should WPA2-AES be presumed insecure? (What is the "Hole196" vulnerability?) I saw it mentioned in an answer here about firesheep, but I've never heard of it -- Should WPA2 be presumed insecure?

WPA2-AES should be considered secure against "outsiders": people to whom you have not given the cryptographic key / passphrase.

WPA2-AES is not secure against "insiders".  People who you have given the cryptographic key can access the network and may be able to eavesdrop on communications of other users.  However, usually this is acceptable and beyond the scope of what we are expecting the network to do for us.

See also How do I protect myself against 'hole 196'? and this summary of hole196.

Also, make sure you read about the vulnerability in Wifi Protected Setup (WPS).  Probably you'll want to disable WPS.  See, e.g., this question for some citations where you can read more about the WPS vulnerability.


How are you able to inject bash script through the user agent I was looking over the new Bash exploit and was looking at this post in particular.

Attack scenarios of the new Bash vulnerability

What I don't understand is how does including bash in the user-agent string cause it to be executed. It seems odd to me that the user agent would ever be executed on the server. I know this i a broad question but I am just looking for a general understanding of how this is allowed to happen if possible.

EDIT:

Doing some further research I read through this which kind of cleared some stuff up for me.

https://stackoverflow.com/questions/2089271/i-never-really-understood-what-is-cgi

Which explains that CGI is setting some environmental variables and some other input via stdin. Why no guard is in place to keep this from simply being a string is beyond me or why you are able to pass a bash function in a header.

What you are refering to is the Shellshock Bug, see https://blog.cloudflare.com/inside-shellshock/

The Shellshock problem specifically occurs when an attacker modifies the origin HTTP request to contain the magic () { :; }; string discussed above.

Suppose the attacker change the User-Agent header above from Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 to simply () { :; }; /bin/eject. This creates the following variable inside a web server:

HTTP_USER_AGENT=() { :; }; /bin/eject

If that variable gets passed into bash by the web server, the Shellshock problem occurs. This is because bash has special rules for handling a variable starting with () { :; };. Rather than treating the variable HTTP_USER_AGENT as a sequence of characters with no special meaning, bash will interpret it as a command that needs to be executed (I've omitted the deeply technical explanations of why () { :; }; makes bash behave like this for the sake of clarity in this essay.)

The problem is that HTTP_USER_AGENT came from the User-Agent header which is something an attacker controls because it comes into the web server in an HTTP request. And that's a recipe for disaster because an attacker can make a vulnerable server run any command it wants (see examples below).

The solution is to upgrade bash to a version that doesn't interpret () { :; }; in a special way.


Keep original message identity when sending email messages several times Please consider the following scenario:

User "A" encrypts and signs message "M" with user "A" private key.
User "A" sends message "M" (and his public key) to user "B".
User "B" decrypts message "M" and reads it.
Up to this point, message "M" has been signed by user "A".

How can user "A" avoid that user "B" sends same message "M" to user "C" and claim that user "B" is the original sender?

Is a digital certificate enough?

I will appreciate a simple explanation about how to avoid user "A" to be left out.

Regards.

User A cannot prevent B signing and sending any message to C. This includes messages B received from A in the first case. But, A can send the message or a digest of the message to C too when sending it to B so that C receives the message (or the digest) first from A and thus can derive from this fact that A had the message before B (and thus might have created the message). Or, A could use a trusted timestamping service so that he can later proof that he had the message before B. Similar there could be a trusted party which receives a digest of all messages or one could even use a public blockchain or hashchain for this which can be used to check in which order the messages were sent and by whom.

  Is a digital certificate enough?

No, a digital certificate by itself does not help.


Should I revoke & regenerate PGP private keys after computer is serviced by Apple Store? I recently had an issue with my MacBook where it wouldn't boot. So I took it in to the apple store, and they said that they would need to send it off to a service center to diagnose and repair it. I received my computer back two days later - working great.

The "problem" is that my Mac is password-protected using FileVault full disk encryption, and the Apple techs needed my FileVault password in order to boot up my computer and test everything out. Normally I wouldn't hand out my passwords, but I needed to get my computer fixed. (EDIT: And to be clear, I also normally would change my password, or remove my private keys, before handing over my computer. But because my computer wouldn't even boot, this wasn't an option.) Since I'm so smart (yeah right), my FileVault password is the same password as my private PGP keys - which are also stored on my laptop. Theoretically (though probably unlikely in reality), an adversary Apple tech could have fixed my computer, booted it up, logged in as me, and poked around to see if there were pgp keys - and then tested out my login password to see if it would give them access to the private keys.

When I set up my PGP keys, I created a secret signing sub-key and master keypair which are not stored on my laptop - they are on a secure USB key. So I can easily revoke the PGP keys and generate new ones, if I decide that I want to do so.

With this in mind, my question is: Should I treat this situation as if my computer had been stolen, and revoke and reissue my PGP keys using the same signing sub-key?

TL;DR

Anytime an attacker has physical or logical access to private key material—even if encrypted at rest—one should certainly consider revoking the exposed keys. In your particular case, you should assume a compromise and act accordingly.

Why You Should Revoke Your Keys

Even had you not violated the principle of "thou shalt not reuse passwords," the fact is that a local attack or an attack on extracted/copied key material is not rate-limited. So, assuming Apple, Google, or the NSA really want to attempt to brute-force your encrypted key, they can do so much more effectively with access to your on-disk key.

Since it would be common sense to try any known passwords before embarking on a brute-force attack, you can (and should) assume that any knowledgeable attacker will do exactly that. Never assume your adversary is an idiot.

In your particular case, you gave the attacker both physical and logical access to your machine. It is both possible and likely that backups of data were made, so even if the technician isn't your direct adversary, you now have no assurances of who has access to your key at rest, or what computing resources may be brought to bear on it.

In short, you handed over your key with your key's passphrase metaphorically (and possibly literally, by the technician) taped to your monitor. You'll likely never know if you were compromised, but you should certainly assume that you could have been.

Why You Might Choose Not to Worry

While Apple (as a company) has plenty of computing and storage resources for backing up your secrets and mounting brute-force attacks on them, it seems unlikely to be in their direct interest. They sell products and services that consumers would like to believe are secure, so deliberately violating that security and trust would be a bad business decision.

Having said that, individual technicians might still be bad actors. However, this possibility is tempered by the fact that Apple techs are unlikely to be professional cryptographers or forensic specialists, and are generally busy people without the time to waste poking around on people's hard drives without a bit more of an incentive than you've identified in your post.

A more likely scenario is that Apple might get a National Security Letter asking them to turn over any data they may have. The NSA certainly has the training and the resources to comb through your files and apply common-sense forensics to avoid brute-forcing your password, but unless Apple is routinely handing over all customer data as part of some bulk collection activity (see above for why this is possible but unlikely), you probably don't need to lose a lot of sleep about this particular scenario.

Finally, threats are all about consequences. Assuming you aren't smuggling state secrets, or have your off-shore accounts and human-trafficking contact information encrypted with the potentially-compromised key, the logical question to ask is: Even if the key was compromised, so what?

If your damage potential is low enough, you could probably go around handing people your private key all day long without serious consequence. I'm not recommending you do so; it's just worth taking your actual risk profile into account to properly assess threats and the consequences of compromise.

Note to Apple Customers

Apple does this a lot, e.g. asking customers to unlock their drives as part of their diagnostic and repair processes. They claim they need access to the OS stored on the FileVault-protected partitions in order to run diagnostics. There may be a technical reason why they can't use a boot disk or network boot to spin up their diagnostics, but without more information I consider it suspect.

As a general rule of thumb, it's best to back up your drive and blow away the FileVault partition before going in for service, or letting them do it for you. While it doesn't make a lot of sense to distrust your hardware or OS vendor, neither should you hand anyone sensitive data on a platter. Just be aware that asking for FileVault passwords is S.O.P. at Apple repair centers, and plan accordingly.


Spoof Windows MACs without restriction How do I spoof the MAC address in Windows without 02 or 00 being the first octal? Microsoft has restricted it to 02 and 00 being the first octal!

The MAC Spoofing works perfectly when I am on Linux distros. I tried searching the internet but couldn't find anything. Is there any workaround for this?

A quick Google search gave me this explanation.

  Setting first octet "02" actually sets the b2 bit indicating that the
  MAC address is locally administered. Looking at this MAC address thus
  indicates that the MAC address is changed by local machine
  administrator. But, its still good if you just want to hide your
  original MAC address instead of spoofing someone's MAC address.

  Another guess on why this works may be due to Windows Network Bridge
  feature. When you bridge 2 or more network adapters in Windows, the
  Network Bridge sets its MAC address to the first network adapter added
  to it with the first octet set to "02". Thus, if the network adapter
  drivers didn't allow the change, it would make the feature not work.

Source: TMAC Issue With Wireless Network & Workaround

So, I guess your best bet would be to use any Linux distro on VMware or VirtualBox and change your mac in that to whatever you want. Linux has no such limitation. :)


Why use Mikrotik hotspot gateway? First of all Let me mention that this whole experiment is for learning purpose and not intended to cause harm or damage.

I am a novice networking enthusiast.Recently I tried to penetrate a wifi network which is open and has no security but authorization is done through a mikrotik hotspot gateway.When a user is connected to this network it redirects user to the gateway webpage on a server and asks to enter username and password for authentication.I could connect to the network after I managed to monitor devices that connect to this hotspot, record their MAC addresses and spoof my MAC address to impersonate one of the authorized devices.I have three questions;

Is it possible to access the routers web interface and modify setting if the administrator changed the default password/username of the router?
Why should a network administrator use this method to secure a network since this can be bypassed by mac spoofing  and it is vulnerable compared to a WPA/WPA2 security?
Is it possible to fix this vulnerability of hotspot gateway?

Thank you

Is it possible to access the routers web interface and modify setting if the administrator changed the default password/username of the router?

Hopefully not but some routers have one or even multiple backdoors. Or in case of MikroTik a CSRF attack against the administrator could be used to change the password if the system is not fully patched.

  Why should a network administrator use this method to secure a network since this can be bypassed by mac spoofing and it is vulnerable compared to a WPA/WPA2 security?

There is no such thing as a 100% secure solution and the more security you want the more expensive and/or unusable it usually gets. To make MAC spoofing impossible inside a WLAN you probably need some kind of authentication of the clients which is more robust than the initial username and password. 802.X provides this but then you would need to install authentication credentials (for example certificates) on each device and maybe special software too. You don't want this in public hotspots so you accept instead the risk of MAC spoofing.

  Is it possible to fix this vulnerability of hotspot gateway?

There are solutions but they affect the usability too much if used in a public hotspot. If used inside a company where one has more control over the connecting devices one can detect and block MAC spoofing.


Most Efficient way of Encrypted Chat I'm creating a server where people can come and talk to each other. I'm mostly doing it for a fun project, here's my question.

I'm using RSA for encryption/decryption, so only the clients will know what's being said. I don't want the server to handle any decrypted text.

My question is, what's the most efficient way of doing this? From my understanding, I'm going to have to give everybody each other's public key's. And once a client says something, it's going to have to encrypt it to each person individually using their respective public key, isn't it? To me that seems extremely inefficient.

Is there a better way to do this?

Thanks

Public key cryptography can, in this case, be used to facilitate setting up a secure channel in which to transmit a symmetric key.  Once the secure channel has been set up, it is not necessary to continue to encrypt and decrypt using the public/private keys.  Instead, generate a symmetric key and use that to encrypt the traffic.  You only have to distribute the symmetric key once, and the traffic need only be encrypted with this key rather than with each public key.  The main challenge is when or if the symmetric key needs to be regenerated, revoked, etc.


Show another number when calling mobile phone Nowadays I heard that some cheaters make mobile calls to steal banking & other private information.They show private numbers like 911 to their victims.

Is it possible show different number to victim when calling another mobile phone.?

Is it possible by using a program or by any other means?

I am not sure how it can be effectively done by directly calling the phone line (such as using phone masking services offered by companies), but I can think of a way of doing that using the data line (wi-fi/3g etc) first and then starting the call.

Attacker creates a program which pretends doing something useful, however it also has an activity/screen which exactly imitates the phone call activity/screen. After installed in the OS, program starts a service which tries to communicate (using 3g or wi-fi) with the server of the attacker when needed. When they want to communicate, phone call imitator activity is started and user is deceived with a number like 911. User thinks he/she is answering the call, however in fact he/she is the one who is calling the attackers phone which is obviously not 911.


What are the ways to identify a DNS cache poisoning attack? Consider a scenario: (at victims end) in DNS cache poisoning attack. When the victim will go to a website (eg: gmail.com), he will be taken to some other phishy website. Now here the URL remains the same, so is there any way to identify that the website he/she is visiting is fake?

Without any help from the site it's really hard, and sadly according to W3Techs statistics many don't still use the technologies that would give you a warning on both DNS cache poisoning and Man-in-the-Middle attacks.

Every sites should have TLS certificates now that they are free and easy to get from Let's Encrypt. All CA signed certificates are at least domain control verified, so you'd get an error if there's an imposter's site.
HTTPS shouldn't be just an option for the user, but sites should upgrade every plain HTTP connection with a redirect. This way, an URL starting with http:// would be an indication of something being wrong.
HTTP Strict Transport Security (HSTS) makes the browser remember the site (and possibly all subdomain) should only be viewed on encrypted connection.

DNSSEC would be helpful, but only if your resolver validates it and your connection to your DNS resolver is secure. That's almost never true on foreign networks.

What could you do as a user? I'd suggest using HTTPS Everywhere. In the normal mode it lists sites that are known of having HTTPS, even if they do not have HSTS or redirect to HTTPS by default. I choose use it on Encrypt All Sites Eligible (EASE) mode and get to decide whether it's actually worth visiting a site that would be served on plain HTTP.