Should organisations allow their employees connect with a VPN software from their own laptops to their machine at work? I saw a few breaches on a very large scale where an organization like JP Morgan suffered a huge breach just by allowing their employees to connect via VPN to their machines at work. Seems that hackers took over JP. Morgan employee computer to connect to his machine at work. Usually, employees connecting to their desktop at work via VPN program that been developed by a company, 2FA and of course they use their own protection measure like a reverse proxy in the backend. I was trying to understand how a company like that could be hacked and what are the possible measures to take for such organizations.

Link to JP. Morgan Study: https://www.sans.org/reading-room/whitepapers/casestudies/minimizing-damage-jp-morgan-039-s-data-breach-35822

From wikipedia:

  A virtual private network (VPN) extends a private network across a public network, and enables users to send and receive data across shared or public networks as if their computing devices were directly connected to the private network.

The situation you describe is no different from me taking my gaming PC (which is undoubtedly full of viruses), bringing it to the office, and plugging it into an ethernet cable. Happy happy viruses now spreading through the corporate network :)

That's why companies prefer to issue corporate laptops over which they can enforce virus scans, etc, and only allow those to connect to the corporate network (whether wired, wireless, or vpn).

(it is possible to do personal-computer-vpn securely, but it's a fair bit more complicated -- you vpn in to a landing subnet from which you can access DMZ'd VDI / RDP hosts, from which you can access your work machine, or something like that. But even there, your personal computer may have keyloggers collecting your corporate passwords and other things you type.)


TrueCrypt External Multimedia Hard Drive I have an external multimedia hard drive (1.36TB).  I made 4 partitions of 350GB each. Then I shredded the free disc space of all the partitions.

Now I want to put Truecrypt on the disk.   I can't put it on all 4 Partitions.  If I put it on all 4 Partitions, I can't use the hard drive for watching TV or films.
So I want to lock 3 partitions and leave one open.

I am worried that I won't get the full Truecrypt protection. Since one partition is open, you can just go to the computer, access the open partition, reformat the other three, then the password is gone and the you can run a file recovery program.

With TryeCrypt, the files are encrypted on the hard disk, so if an attacker formats the partitions and he use a recovery software, the files will still be encrypted. By the way, even if all your parition would be encrypted, an attack could still format your hard drive.

The attacker needs the key to decrypt your files. The key is kept in the RAM of the computer who is decrypting the files. You must protect your computer from deep freeze attacks and of course you need to protect your computer from key logger that would steel your key when you type it. Also, you need to put a long key so a brute force attack will fail to decrypt your files.


Executable files in email attachments on UNIX .EXE files are a danger in email attachments, and are usually blocked by Windows email clients. How is this on UNIX/macOS, where executables don't have an extension?

Based on the file data, how do you determine if the file is a program executable (disregarding execute permissions, text-based scripts and files like PDF that indirectly execute a viewer)? Do you simply run file <attachment> and block the file if the result is something like executable?

I'd also like to understand how this works on a low level. I gleaned /usr/share/file/magic/elf. The format is a bit cryptic, but would the following C code reliably detect a Linux executable?

if(strcmp(filedata+0, "\x7fELF") == 0)

What would be the corresponding test for macOS?

UNIX alike systems like Linux or MacOS do not run any executable files just because they have a specific extension. To make a file directly executable it needs to have the executable-bit set (chmod +x file) which will not be done done automatically when saving the attachment.

Still, there are many kinds of files which desktop environment on top of Linux (and other OS) like GNOME, KDE,... will automatically open. This is for one based on the file extension similar to what Windows does, i.e. *.doc files will be opened with some office suite, *.pdf with a PDF-Viewer etc. If the extension is missing then most desktop environments will look at the "magic" of the files, i.e. use libmagic to determine the kind of file and open it in the appropriate application. On MacOS there is also an additional mechanisms where the file type and application is includes as attributes (fork) in addition to the file but these information are usually lost when transferring a file through mail (although some archiving programs preserve these attributes).

But, it will NOT automatically mark downloaded files executable and run them. It will also not directly execute shell-script, Perl-Scripts, Python-Scripts etc which don't have the execute-bit explicitly set.

It is though possible that you've downloaded an archive and extracted it. Specific kind of archive formats (like Tar, usually with extensions like *.tar, *.tgz and similar) will include file permissions like the executable bit and these will be usually preserved when extracting the archive. In this case no additional setting of the executable bit is needed and a program could be directly executed.

Thus, withstanding bugs in PDF viewer, Office application or similar applications which are automatically started when you click on a file and withstanding archives, you are generally more safe in Linux since it will not automatically start programs downloaded from somewhere. On the other hand, applications could set a special attribute to files in Windows to specify that the origin of the file is not trusted, which causes Windows to ask for confirmation before executing the file.

If you still want to filter for executable files in attachments you might use libmagic or the libmagic based tool file to detect the file type. Note that these are only heuristics and detection might in theory return a different type, especially for very similar file types (like all the ZIP based office documents, JAR files, ZIP files..). But given that ELF binaries or files with an explicit interpreter definition on top (i.e. #!/usr/bin/python) have a clear structure one can rely on these heuristics for these file types.

Apart from that note that recent Windows versions not only use the file extension to determine what to do with the file. If the file has no extension which is associated with an application it will try to detect the file type without extension similar to how it is done in Linux.


Forward Secrecy in TLS-PSK I'm reading RFC4279 (Pre-Shared Key Ciphersuites for Transport Layer Security), Section 7.1, which is about Perfect Forward Secrecy. In that section, it's said that PSK/RSA_PSK  ciphersuites don't provide forward secrecy. But, if I'm not wrong, PSKs are used to form premaster secret, which is then used with random numbers to create master secret. Doesn't that mean even PSKs are compromised they should provide forward secrecy (because in every session random numbers will force to create new keys)?

Thanks.

You're correct that PSKs are used to form the pre-master secret, but Perfect Forward Secrecy (PFS) is not just about creating unique pre-master secrets.

PFS is about protecting all other sessions if one session is compromised.  For example, if I break the RSA key for one session and this key is used for all subsequent sessions; I can now decrypt the pre-master secret for all sessions.  It doesn't matter that the pre-master secret is unique to each session because I can see what it is anyway.

What you want for PFS is to create unique key exchange parameters for each session.  This is what Ephemeral Diffie-Hellman (DHE/ECDHE cipher suites) provides.  New Diffie-Hellman parameters are generated for each new handshake with a client.  If one session is compromised the other sessions are still secure because the exchange will have unique parameters.

See this answer for more details on PFS and Ephemeral Diffie-Hellman cipher suites.


Password Hashing Without a Unique Salt I have a question about password hashing. This is not a question about the the BEST POSSIBLE method of hashing passwords, but rather a more utilitarian question about what is sufficient to hash a password without standard rainbow tables being an issue.

Let me outline a hypothetical scenario. You have an application that is designed without unique salts, and for whatever design reasons, it would be a huge modification to change the application to work with a unique salt for each individual user. So instead of rewriting a huge part of the application, we are looking for a way to hash passwords that is more secure than a pure SHA1 (or whatever standard hashing algorithm), but doesn't involve unique salts.

I'll give two examples of solutions that don't involve unique salts. They each have the obvious advantage of rendering a rainbow table for a pure SHA1 (or any other standard hashing algorithm) useless. Each does, however, have the disadvantage of being able to create a rainbow table for that particular strategy. But if you think about it, using a unique salt has the same vulnerability, if you were to target a single user.

The simplest idea is to have a single salt for all passwords hard-coded. The second is to come up with a more complicated algorithm, such as splitting a password in two by a defined set of rules, hashing each, then hashing the concatenation of the two partial hashes and store that. This can be extended to any algorithm you like.

Is this method sufficient for most applications? Neither is obviously as secure as a unique salt for each user, but if you were targeting a specific user it seems neither more nor less secure if you know the salt for that particular user.

Is that correct? And is it a viable solution for some (or maybe most) cases?

The rationale for unique salts is not simply to combat rainbow tables.  If your entire database of passwords is hashed without salts (or with only one salt), then an attacker can attack your entire password database simultaneously instead of being forced to attack each password individually.

Also, as mcdowella has pointed out, a password database which is not protected by unique salts can potentially fall victim to an attacker extrapolating information from the fact that multiple users are observed to share the same password.

Neither of your solutions address either of these problems.  You can make the attack more expensive computationally by using something more secure than sha1 (a high itteration count PBKDF for instance) but that isn't a replacement for unique salts.  They are easy to implement and the cost/benefit ratio of unique salting in terms of additional computation time and  increased difficulty to attack is better than pretty much any other single approach.


VPN encryption per device When you use the same VPN (for example NordVPN) with same username and password on several devices, if one device is compromised/hacked, can it be used to decrypt the traffic of the other device using the same VPN? Or does it weaken the encryption of the same device in any way?

I guess it doesn't, since the encryption keys are different for each device I think, but I wanted to have your advice.

No, such a breach should not happen as any respectable VPN service will generate separate keys for each client.

Your data is encrypted, so even if someone that compromised the network does look at what you’re sending, they only see encrypted information and not raw data.


To what extent should we defend against leaked credentials being tested against our system? We see these kinds of attempts with some frequency. Normally a leak has happened from some other 3rd party, and an attacker has a big list of known account + password combinations that they can try against other systems. They then hit our system (in this case, a website login form) testing all the credentials they have for a match.

Given that people are unreliable at using unique credentials, and that not everyone on our platform has opted in to using 2FA (and we don't want to force it), are there additional steps we can be taking to help protect users, or efforts we can undertake to combat being used as a testing ground for leaked lists?

(It's also very annoying having to scale up large numbers of instances because some attacker is throwing vast numbers of concurrent attempts per second at our infrastructure!)

Obvious precautions we already implement:

Rate limiting attempts per account, combined with a temporary lockout, but that doesn't help against a list of single entries.
Rate limiting attempts per IP address, but that doesn't stop when the testing is distributed over a large number of nodes. Typically we see enumerations happening from 5k+ addresses, and that means at least 25k accounts can be tested before we start filtering those addresses.

We are evaluating the idea of using email confirmations as 2FA (for users not opt-ed in to using a 2FA device with us), when we see a login from a device we don't know, but we will first need to measure the customer impact.

Can (and should) we be undertaking further efforts to protect users?

Strongly consider converting to 2FA emails for first-time computer registration.

"Dear Andy Savage, we've noticed this is the first time you've used this browser to log in to our service.  To help keep your account safe, we've sent an email to your registered email address at a****e@g****.com.  Please click the link in the email to confirm this really is you."

Most of your customers have already received a dozen such letters, and will barely notice the "inconvenience" you're imagining.  If they bother to consider it, they might believe you're doing some magical security things that they don't understand, or they might think you're just blowing fake security smoke at them.  And yes, some will be confused and/or frightened because it's not what they expect.  You can minimize that by gathering existing login info now, and pre-setting cookies on all their existing browsers today so that they never even see the prompt.

Whatever fallout you get from this will pale in comparison to the blame you will receive for any Account Take-Overs that happen.  It's one thing to confuse them, but they'll have a completely different reaction if they think that you were hacked or you allowed them to be hacked (hint: most clients can't or won't make the distinction.)


Why should I hide API keys? I need to integrate my android app with dropbox, basically all I want is for the user to choose a file from his dropbox and give it to my app. In order to do that I'm using dropboxChooserSDK, and it requires an API key to access dropbox.

From my first instinct was to search on how to hide the key. Looking deeply into it I have noticed that there is no silver bullet to solve the problem (I should have expected as much).

On the other hand there doesn't seem like there is much harm in having my dropbox api key exposed to the world given the prupose of the key as explained in their reference documentation:

  If you're building a developer tool on top of Dropbox, your developers
  will need their own Dropbox app keys

  While we encourage developers to use our official SDKs and libraries,
  we know there are a lot of different approaches to building frameworks
  and APIs. Regardless of how an app makes use of the Dropbox Platform,
  we need to know what that app is so we can let users know which apps
  are accessing their data. For that reason, if you provide software or
  services that wrap the Dropbox Platform for other developers to use,
  those developers must still sign up for their own Dropbox app key.

But that made me think, about the question, how much effort should I put into hiding my API keys? My intuition tells me to use a back of envelope calculation to estimate the cost/benefit trade-offs individually, but I also read here that there is ongoing discussion about such problems (though I couldn't find it).

What's the general understanding regarding securing API keys?

I don't know anything about Dropbox in particular, but my understanding of  API keys from other storage providers like Google Drive, Amazon S3, etc is that they allow users to log in either through their apps, or through 3rd party apps and they want to be able to track which is which. The quote in the question makes it sound like this is about privacy: letting end-users know which apps are accessing their data and be able to revoke permission on an app-by-app basis.

There is also often a billing angle: Google Drive, for example, offers a free service directly to end-users through their own apps, but charges some $/gb to developers who want to piggyback on their infrastructure inside another product. Whether that app developer charges that to their users through a subscription, or just swallows it as a cost of business, is up to them.

This is where API keys come in: without an API key, an incoming request to the Dropbox server is just a request; you know which end-user it is because they have logged in, but you have no way of telling whether they are using your app or some 3rd party app, and if so, who to bill the bandwidth to. By embedding an API key in your app, you are linking each request your app makes back to your developer's billing account.

Since Android .apk files are fairly easy to reverse engineer, an attacker could conceivably extract your API key, use it in their app, and you'd get the bill.

Is the effort of protecting the key worth the risk? That's up to you. If you monitor your usage frequently or have set some kind of usage cap / alarm and are confident you can revoke the key quickly if fishy things start happening, then you're probably fine.

UPDATE:
As @XiongChiamiov points out in comments, you should also consider the disruption to service if you do need to revoke your key. Let's say you start seeing abnormally high billing or hit your pre-set usage cap. Your response would probably be something like:

scramble to implement better API key protection in your app
publish a security update to the Play Store with a new API key
revoke the old one.

The Dropbox feature of your app will fail until users update their app through Google Play. This will certainly cause some confusion among your users. Whether this is a big enough risk to worry about at this point is up to you.


Finding wpa2 key length Is it possible to determine WPA key length through a successful handshake?

Below is a screen capture showing the packet capture session of interest as displayed in Wireshark:

My question came from that little phrase "WPA key length".
What does that phrase mean?

My question came from that little phrase "WPA key length". What does
  that phrase mean?

It appears to mean the length of the WPA key in bytes.

The "WPA Key" element is displayed in your figure right below the "WPA Key Length" element. The "WPA Key" appears in your figure as a string of 48 ASCII characters representing a sequence of 24 bytes. E.g., "DD" represents the byte 0xDD, which is 221 in decimal. E.g, "16" represents the byte 0x16, which is 22 in decimal.


May have been hacked, tips on how to proceed? So, let's try to explain this as clearly as possible.
I have three gmail accounts, A B and C. A and B share a long, random and secure password, never used anywhere else. Account C has a relatively weak password. Account C is not used for any relevant stuff. Account A appears as a mailto link in my personal website, constructed using javascript, but a bot with a javascript engine can acces it easily get it.

And that's what I thought happened, when three days ago email account A started being spammed with registrations to many websites and mailing lists around the world. I thought some bot grabbed my address so I created gmail account D and proceeded changing my most important accounts to use account D, and warning people and contacts to send me mail to D instead of A.

But today, a few hours ago, I received a push notification on my android phone saying 'Somebody has your password', with a supposed login from my country, but hundreds of km from my location. This happened to accounts B and C, but NOT to A and D. Now is when I start being worried.

Turns out, my computer started lagging randomly when playing some games a while ago, as if the hard drive was malfunctioning. I have two drives in RAID 1, and both pass SMART tests as healthy.

My paypal and bank accounts are fine. No harm has been aparently done, but I am worried my personal computer (running windows 10) got compromised and somebody is 'preparing the terrain' to finally strike. I enabled two factor authentication on my google accounts and changed the password for websites where i have card information stored.

So what should I do to be sure my accounts are not compromised? What are your thoughts on the matter? I am really busy right now and completely reinstalling the operating system on my computer right now would imply a hugue loss of time and lots of stress. I do not know much about personal security and hacking despite being a developer.

UPDATE: Thank you for the answers. The hacker finally striked. It turns out they hacked some personal account with my credit card stored in it which I forgotten I had, and charged a ~1500 euro bill. Fortunately I catched it in time, since I was checking all the mails in my account being spammed in case it was due to something like this. To be sure, I cancelled and reissued all my credit cards and asked/warned my bank. No money was ever charged because I cancelled everything in time.

I ran a benchmark in my computer and indeed there is a faulty drive, also ran a scan with my antivirus software and everything seems ok.

Turns out account A was also accessed from that IP, so that would be all three accounts accounts I have on my phone, while my phone was using 3G, so maybe my carrier assigned my phone a far away IP? I don't know if that's possible, but I have enabled 2 factor in all my gmail accounts, so I think I should be safe without erasing my hard drive. Other people sharing my wireless haven't had any problems for now. I know fully erasing my computer is the safest option, and also not using backups to restore, but that would mean hell for me during at least a couple of weeks.

Personally, these are the steps I would take if I thought my personal computer had been compromised enough that the traffic was being captured. The following assume you have a friend with non-compromised media.

Go to a friends house and use their computer to login to all accounts and set them to new, secure, unique passwords. If 2 Factor Authentication is available do it. Bank accounts, phone bills, etc. etc. All of them changed.
Wipe the personal computer with Darik's Boot And Nuke (DBAN) on a bootable flash drive created at your friend's with your friend's flash media
Reinstall Windows from a fresh media created using friend's flash drive and computer.
If you can be sure your backups haven't been compromised, restore from backup.


Best way to report a foreigner attacker's ip to authorities? I have been under attack last week and I was able to trace down the attacker and get his IP address. The attacker was located in Germany but I live out of Europe?

From your experience what is the best way to report an international cyber crime? is it worth reporting at all?

There's always an "Abuse" email address on the whois of a netblock for reporting misuse of an IP address.

You can use http://whois.domaintools.com/ to do a whois lookup to get the address.

Is it worth your time? That's your call. Will it lead to anything? Nothing you'll ever see. But many of the sites I fix come from people who were first alerted of the problems on their server by someone sending the hosting company an "abuse" notification email. So it definitely can make a difference.

Note that the IP address you track down is almost never the attacker himself but rather a hacked server or computer that he's using as a relay. So keep that in mind. You're not alerting the authorities on the whereabouts of a miscreant; you're notifying someone that his computer has been compromised.

EDIT TO ADD

You give the information you have to the appropriate authority, and then you're done. That it. As a rule, hosting companies will not share personal information of their clients unless you are local law enforcement with the appropriate warrant or court order. It's their liability if they do otherwise.

Don't expect a follow-up report from them, don't expect names or arrests or anything more than an acknowledgement that they heard you -- sometimes not even that. These companies often deal with dozens of these reports a week or more. Their abuse team will deal with it, and they appreciate your assistance as they want to keep their network clean, and your report will probably trigger several days worth of activity. But they have a clear-cut policy that they follow to the letter for liability reasons, and it intentionally doesn't include reporting back the original reporter. Nothing against you specifically.

Also, remember that though you found the hacker, It's almost certainly not his account on the server.


What is the most hardened set of options for GCC compiling C/C++? What set of GCC options provide the best protection against memory corruption vulnerabilities such as Buffer Overflows, and Dangling Pointers? Does GCC provide any type of ROP chain mitigation? Are there performance concerns or other issues that would prevent this GCC option from being on a mission critical application?

I am looking at the Debian Hardening Guide as well as GCC Mudflap.  Here are the following configurations I am considering:

-D_FORTIFY_SOURCE=2
-fstack-protector --param ssp-buffer-size=4
-fPIE -pie
-Wl,-z,relro,-z,now (ld -z relro and ld -z now)

Are there any improvments that can be made to this set of options?

We are most worried about protecting WebKit.

I don't code for gcc, so hopefully someone else can add to this, or correct me. I'll edit it with responses. Some of these will not work for all circumstances.

-Wall -Wextra Turn on all warnings to help ensure the underlying code is secure.
-Wconversion -Wsign-conversionWarn on unsign/sign conversion.
-Wformat-securityWarn about uses of format functions that represent possible security problems.
-Werror Turns all warnings into errors.
-arch x86_64 Compile for 64-bit to take max advantage of address space (important for ASLR; more virtual address space to chose from when randomising layout).
-mmitigate-rop Attempt to compile code without unintended return addresses, making ROP just a little harder.
-mindirect-branch=thunk -mfunction-return=thunk
Enables retpoline (return trampolines) to mitigate some variants of Spectre V2. The second flag is necessary on Skylake+ due to the fact that the branch target buffer is vulnerable.
-fstack-protector-all -Wstack-protector --param ssp-buffer-size=4 Your choice of "-fstack-protector" does not protect all functions (see comments). You need -fstack-protector-all to guarantee guards are applied to all functions, although this will likely incur a performance penalty. Consider -fstack-protector-strong as a middle ground.
The -Wstack-protector flag here gives warnings for any functions that aren't going to get protected.
-fstack-clash-protectionDefeats a class of attacks called stack clashing.
-pie -fPIE Required to obtain the full security benefits of ASLR.
-ftrapv Generates traps for signed overflow (currently bugged in gcc, and may interfere with UBSAN).
-D_FORTIFY_SOURCE=2 Buffer overflow checks. See also difference between =2 and =1.
-Wl,-z,relro,-z,now
  RELRO (read-only relocation). The options relro & now specified together are known as "Full RELRO". You can specify "Partial RELRO" by omitting the now flag.
  RELRO marks various ELF memory sections readonly (E.g. the GOT).
-Wl,-z,noexecstack
  Non-executable stack. This option marks the stack non-executable, probably incompatible with a lot of code but provides a lot of security against any possible code execution. (https://www.win.tue.nl/~aeb/linux/hh/protection.html)
-fvtable-verify=[std|preinit|none]
  Vtable pointer verification. It enables verification at run time, for every virtual call, that the vtable pointer through which the call is made is valid for the type of the object, and has not been corrupted or overwritten. If an invalid vtable pointer is detected at run time, an error is reported and execution of the program is immediately halted.(https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html)
-fcf-protection=[full|branch|return|none]
   Enable code instrumentation of control-flow transfers to increase program security by checking that target addresses of control-flow transfer instructions (such as indirect function call, function return, indirect jump) are valid. Only available on x86(_64) with Intel's CET. (https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html)

If compiling on Windows, please Visual Studio instead of GCC, as some protections for Windows (ex. SEHOP) are not part of GCC, but if you must use GCC:

-Wl,dynamicbase Tell linker to use ASLR protection.
-Wl,nxcompat Tell linker to use DEP protection.


Why isn't its mandatory for the keyservers to be only available via HTTPS? If I Google for inurl:http+keyserver, on the first 10 pages of hits I can find these:

http://pool.sks-keyservers.net/
http://keyserver.ubuntu.com/
http://www.uk.pgp.net/pgpnet/wwwkeys.html
http://www.rediris.es/keyserver/
http://www.keyserver.net/
http://pgp.uni-mainz.de/pks-commands.html#extract
http://www.pgp.net/pgpnet/wwwkeys.html
http://pgp.nic.ad.jp/
http://keyserver.opensuse.org/

And these are only the www based keyservers. Do they have zero clue about IT Security? HTTPS isn't a holy grail, but it is much better than plaintext! Correct setup of HTTPS requires that HTTP isn't enabled (at least a redir!) and a valid HTTPS cert...

Question: Why isn't its mandatory for the keyservers to be only available via HTTPS? Todays Let's Encrypt is free and requires no maintenance. Is there any good argument for not using a secure (encrypted and authentical) connection?

UPDATE: during a MiTM, the keys that are not sent via HTTPS can be altered, thus it doesn't matter that anybody can upload keys to keyservers, the whole thing is already lost! HTTPS would need to be mandatory! At least a better chance!

Need for HTTPS for PGP keys?

For PGP, we already have a PKI mechanism build in, called the web of trust, so we don't necessarily need HTTPS keyserver.

Even if the key servers did serve their keys over HTTPS, you couldn't be sure of the correctness of the keys, as anyone can submit arbitrary keys to the server. Serving the untrusted keys over HTTPS wouldn't make them trusted all of a sudden.

Need for HTTPS in general?

So there is no reason why PGP keys specifically should be served over HTTPS.

There are still valid arguments for HTTPS though, mainly privacy and integrity related. See for example Let's Encrypt Everything.

Why don't the keyservers force HTTPS?

Most of those pages either do not support HTTPS or do not have a valid certificate, so forcing all traffic over HTTPS would not be a good idea, as it would make them less accessable.

But why don't they support HTTPS? Probably because it is too much trouble for them to set up. Sure, Let's Encrypt provides free certificates, but somebody still has to set them up.


Google Chrome obsolete cryptography I have a apache server running and following configuration for ssl:

 Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
 SSLProtocol -all +TLSv1.2
 SSLCompression Off
 SSLHonorCipherOrder on
 SSLCipherSuite "ECDH+AESGCM256:DH+AESGCM256:ECDH+AES256:SH+AES256:RSA+AESGCM256:RSA+AES256:!aNULL:!MD5:!kEDH:!DSS"

In Chrome i got the same "problem" as the user asked here: Google Chrome "Your connection to website is encrypted with obsolete cryptography"

Can anyone tell me what i have to change in this configuration that i get "modern cryptography"?

My certificate is signed with SHA512withRSA and I only want to support 256-Bit chiphers.

When looking what ciphers you actually provide:

openssl ciphers -V 'ECDH+AESGCM256:DH+AESGCM256:ECDH+AES256:SH+AES256:RSA+AESGCM256:RSA+AES256:!aNULL:!MD5:!kEDH:!DSS'

      0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
      0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
      0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
      0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
      0xC0,0x14 - ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
      0xC0,0x0A - ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
      0xC0,0x32 - ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
      0xC0,0x2E - ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
      0xC0,0x2A - ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
      0xC0,0x26 - ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
      0xC0,0x0F - ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
      0xC0,0x05 - ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
      0x00,0x9D - AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
      0x00,0x3D - AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
      0x00,0x35 - AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1

You provide ciphers with GCM, which is what you need for "modern cryptography". But you provide only ciphers with SHA384, which is not supported by Chrome. Thus none of the GCM ciphers can be used by the client and only the "obsolete cryptography" ciphers can be used.

  My certificate is signed with SHA512withRSA and I only want to support 256-Bit chiphers.

You should provide adequate security and not "mine is bigger than yours" security. AES128-GCM-SHA256 is adequate and supported by Chrome.

I recommend reading https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility


Alternative forms for special characters in terminal I was solving a problem on a popular hacking for fun website, when I got following idea:

Is it possible to represent - for example a '/' (just the slash) in the terminal (linux) in another way - for example hexadecimal:

example:

cd /etc/

as

cd %2F etc %2F

is this somehow possible? Even though in this example I am using a special character (%) again.

Yes, this is possible. In most shells, there are plenty of ways to do this. Any way you can encode and decode something in a subshell into ASCII will work. A few examples for bash:

cd $(printf '\x2fetc')
cd $(base64 -d <<< 'L2V0Ywo=')
cd $(awk 'BEGIN{printf("%cetc",47);}')
cd $(cut -b1 <<< $HOME)etc
eval $(base64 -d <<< 'Y2QgL2V0Ywo=')

Everything in the subshell is evaluated first, so these all become:

cd /etc

There are countless other ways to do this, many far more obfuscated than anything I've put here. But if all you want to do is change directories without using a /, any of these should suffice perfectly. Note that some of these use bash-isms and are not perfectly POSIX-compliant.


Is it possible to create a false charger that drains a device's power? Inspired by the idea of the USB Killer, I was wondering if it'd be possible to create a device that, when plugged into a mobile phone/laptop/whatever charging port, drains the charge of said device rather than charging it.

I'm inclined to assume it's not possible because a) I imagine there'd be something on the internet if it was and b) in an episode of Mr. Robot, a hacker gets a target to leave their phone unattended on charge by sending "100 large MMS files" to drain the battery, whereas I assume if a drain attack was feasible he would've done that. I don't know much about electronics though.

Certainly is easily possible. Modern smart phones have an USB otg mode, in which they play host to things like USB drives, mice, SDR dongles. In order to do so, they power these devices. So yes, you can design a charger that first charges the phone, and after a while, presumably after the user leaves the device unattended because he's certain it's getting charged, reverse their role.

However, I'm not seeing purpose in that. Discharging a phone is not a security breach. Getting physical access to one is. And as soon as a user leaves their phone unattended, you've got that. Twice that if he also was unhindered by standard security etiquette not to plug in his phone to unknown USB ports.


sqlmap not finding a proven vulnerability I'm testing a wordpress site with the jetpack plugin installed. According to: https://www.exploit-db.com/exploits/18126/ this plugin should be vulnerable to SQL injection (found with sqlmap) but when running the last updated version of the tool against the target, it says that parameters "id" and "1" are not injectable but exploit DB say otherwise... level and risk switches are on maximum values... Any ideas?

Several things to keep in mind:

The exploit has not been confirmed at exploit-db.com as stated by Michael in the comments.
The server could be running a WAF that returns 200 OK headers to confuse SQLMap.
The server could be running something that filters out "bad" characters in POST/GET request which in result voids the exploit.

Try executing the exploit manually or with a tool such as Postman in Google Chrome. That way you have a better view of what the server is returning.


Are DSA keys breakable? Are the DSA keys breakable? If so, what is the maximum key size that is breakable with the latest technology ?

Why are DSA keys not used during authentication?

Can we use DSA keys for encryption?

To our knowledge, DSA keys of adequate size cannot be broken with existing technology. There are, as usual, details.

A DSA key lives in a group which is incarnated by three big integers, called p, q and g. These are called the "DSA parameters" and may be shared between public keys from distinct people; however, Tradition is that everybody has his own parameters. Security will depend on the sizes of p and q.

p is a big prime. It must be so that discrete logarithm is hard modulo p. Theory has it that breaking discrete logarithm has roughly the same cost as breaking a RSA key if the same size; in fact, DL may be a bit harder. Current World record on DL is for a 530-bit modulus, to be compared with the 768 bits for the current RSA record (but the latter used more computers). Therefore, a 1024-bit prime is currently in the "grey zone" of "not breakable yet, but this seems reachable with existing technology, provided that we build a very specific custom machine which will cost a pretty penny" (rumour has it that it can be done for less than a billion dollars, but not substantially less). A 2048-bit DSA public key will be fine (not breakable with todays nor tomorrow's technology).

q is a smaller prime; it must be so that q divides p-1. The DL is for a subgroup of size q. While we know of sub-exponential algorithms for breaking DL when considering the size of p (which is why we want a p of 1024 bits or more), the same cannot be said for the size of q. To make the story short, a q of 224 bits or more will put you way beyond any break.

In most key strength estimates, DSA and RSA keys of the same size are assumed to offer similar levels of protection.

It so happens that for quite a long time, the DSA standard specified that the size of p and q had to be exactly 1024 bits and 160 bits, respectively (an older version of the standard mandated a size of p between 512 and 1024 bits, which was then changed to "just 1024 bits"). While the current standard allows for longer keys (e.g. 2048/224, which is good), there are a lot of deployed implementations which won't accept anything else than 1024 bits.

1024/160 is still unbroken, but "barely" (breaking such a key requires an awful lot of money, but not sci-fi level technological advances).

An extra point is that actual weaknesses very rarely stem from the key size. Usually, systems are broken through implementation flaws, not through brutally breaking the key. In particular, DSA requires, for each signature, the generation of a new random value (called k) which must be unpredictable and uniform in the 1..q-1 range. Such a process can be botched (Sony reused the same value for several signatures in the PS3 system, thus revealing their private key). DSA signatures require some care. There are solutions but they are not widely deployed yet.

In practice nobody uses DSA; everybody does RSA, and when they switch to something else, they go straight to ECDSA, the elliptic-curve variant of DSA (elliptic curves are very trendy). There still are many software who support DSA, because there was a time when it was mandated for interoperability with US federal systems (that was when RSA was still patented; the US government standardized on DSA to avoid the patent issues).

A DSA key, by definition, is suitable only for DSA, which is a digital signature algorithm.

Mathematically, a DSA public key could also be used with Diffie-Hellman, which is an asymmetric key exchange algorithm, i.e. as good as asymmetric encryption in practice (because everybody does hybrid encryption). However, standardization committees have so erred that DSA and DH public keys don't get encoded the same way. The DH standard is not freely available, so many opensource software don't implement it (because most opensource software is developed by people who devote their time but not their money to the task). This discrepancy is resolved for the elliptic-curve variants (a certificate with a public key for ECDSA actually contains an "EC public key" which is not specific to ECDSA; the same format is used for a public key for ECDH).

Note, though, that you should normally keep signature and encryption keys apart from each other (see this answer).


Buffer overflow with setuid bit enabled I am trying to exploit a buffer overflow vulnerability on a testing environment.

Although I have managed to write a specific address at the return address, the stack is executable and I have the shell code ready.

When i use them, the shell I get has my own UID and not the executable's owner privileges.

Why is this happening?

man bash:

  If  the  shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, ... and the effective user  id  is set to the real user id.

See also (Ubuntu) setuid bash doesn't work, Setuid bit seems to have no effect on bash and many other resources.


What's the difference between the endorsement key and the attestation identity key within the TPM? I'm trying to make notes about the TPM and what it does. More specifically I'm looking at the 3 RSA key pairs: the 'endorsement key', the 'storage root key' and the 'attestation identity key'.
This is what I have written so far:
The ‘Endorsement Key’ is an RSA key pair where any data sent to another device is encrypted using the private key and the receiving device decrypts it with the public key, so it knows the data is trusted. This is created when the TPM is manufactured (not user-specific)
The ‘Storage Root Key’ is a pair of RSA keys within the TPM and is used to protect TPM protected keys created by applications and stored outside of the TPM, so that these keys cannot be used without the TPM. It's created when you take ownership of the TPM (If user changes so does the key)
However, I am now trying to research the use of the attestation identity key but don't understand how it is different from the endorsement key? If anyone could explain in simple terms because this is all new to me I would greatly appreciate it :)

Unfortunately there is not a single source of truth about attestation. I'll try to make it as clear as possible and cite when necessary.
TL;DR: The Endorsement Key is used to prove that you are talking to a real TPM. However, it cannot be used for signing. The AK can be used for signing and is associated with the EK.
Endorsement Key
You can consider the Endorsement Key (EK) fixed per TPM. Actually, the EK is the primary key of the endorsement hierarchy. As such, it depends on the Endorsement Primary Seed (EPS) which is really fixed for the lifetime of the TPM and a so-called template which e.g. determines if the EK is a RSA or a ECC key.
              EPS (random, can never be changed)
               |
            +-----+
template  ->| KDF |
            +-----+
               |
               V
               EK

Assuming, you use the default template, the EK is unique and not changeable for the TPM. You cannot change it ever. This raises privacy concerns which I will cover later. Also note, that the EK private key will never be disclosed by the TPM.
Additionally, a TPM typically provides an Endorsement Certificate (chain) which is saved on the TPM storage (e.g. ECC EK certificate: NV index 0x01c0000a, see TCG EK Credential Profile). This EK certificate contains the EK public key and is signed by the manufacturer. With that certificate you can verify, that the EK public key is associated with a genuine hardware TPM produced by the manufacturer.
I mentioned earlier, that disclosing the EK public key would violate our privacy (since we can never change it). Therefore, the TPM will not allow us to use the EK for signing. That is the reason why we need an Attestation Key (AK), previously also called Attestation Identity Key (AIK).
Storage Root Key
The Storage Root Key (SRK) is easy. It is the primary key of the owner hierarchy, that is the "father of all (normal) keys". All keys used by the owner of the TPM for signing and encryption are usually associated with the owner hierarchy and thus children (or grandchildren etc.) of the SRK. In fact, being a child of the SRK means internally being encrypted (= wrapped) by the SRK.
Attestation Keys
Now comes the tricky part. The term Attestation Key (AK), previously Attestation Identity Key (AIK) is defined very loosely. Basically any (restricted) signing key can be an AK.
TPM Spec Part 1, 25.3.1

A restricted signing key is occasionally referred to in this specification as an Attesting or Attestation Key.

The purpose of AKs is to sign data (e.g. PCR values) to prove that they originate from a real TPM (without having been tampered with). Remember, we cannot use the EK for signing directly.
There are two types of AKs I know of.
AK with AK Certfificate
First, the AK specified in the TPM Spec Part 1, 9.5.3.1. Basically, there is a trusted third party called Attestation CA with an own root key and a root certificate. The Attestation CA does a) verify the if a TPM is genuine via its EK Certificate and b) issue AK certificates if a TPM is genuine.
Now, different AKs and their corresponding AK Certificates can be used for attestation for different services (e.g. Google, Facebook). The service providers use the Attestation CA root certificate to verify if the TPM is genuine.

An external entity called an "Attestation CA" attests to an asymmetric key pair [AK] in a TPM in order to vouch that a key is protected by an unidentified but genuine TPM and has particular properties. This attestation takes the form of a credential [AK Certificate] that vouches for information including the public key of the key  pair.

Usually, this type of AK is associated with the owner hierarchy and thus a child (or grandchild etc.) of the SRK.
I think this tutorial might be helpful.
AK associated with the Endorsement Hierarchy
There is second approach to AKs. As I explained, the EK cannot be used for signing directly. However, it can be used to wrap (= encrypt) other keys. Therefore, you can create a signing key (AK) associated with the endorsement hierarchy.
Again, the service provider needs a mechanism to prove that a TPM is associated with a good EK / EK Certificate. In this case, the AK used is encrypted (= wrapped) by the EK. Only if a TPM can load (= decrypt) the AK under its unique EK and use it to sign data, it is a genuine TPM. In this case, the TPM loses its anonymity since the service provider needs to know its EK.
This approach is briefly described in this talk at LCA 2020 by Matthew Garrett.


What is the best tool to anonymize your scans (network/ports)? What are the best tools to anonymize my port scanners and vulnerability assessment tools  (like nmap , metasploit ) ...?

I have been using Backtrack and tor network with proxychains to do this, but tor has limits and I would like to know what other tools are there to do this. I want to run my tools and be hidden as possible.

i was studying in a penetration testing course so they ask us to test this in their lab so  we get to know how bad guys (black hat hackers) work , this is just for learning and it is not about harming anyone

I'll assume you want to know what techniques the bad guys use to help defend your self against such threats.

Nmap has at least two anonymous port scanning methods.  The two that I know of are are TCP Idle Scan and the FTP bounce scan.  Both of these involve using a 3rd party to facilitate the scan.  The nmap book is pretty awesome.

For metasploit you need a real connection to your target. Tor is a good choice,  war driving and breaking WEP/WPA is another method (though usually illegal).   Getting a list of anonymous proxies is a classic,  tools like Charon and YAPH can help.  These tools will tell you if the proxy supports TLS and if it is in fact anonymous,  or if it spills information about the client (such as the x-forwarded-for http header).


What is the latest samba vulnability, and should I care? I've seen this post on Slashdot.

Quote:

there were no signs yet of attackers exploiting the vulnerability in the 12 hours since its discovery was announced. But she said it had taken researchers only 15 minutes to develop malware that made use of the hole.

Question: should I be worried about this, if i'm using Windows 7 and Ubuntu 16.04 LTS, both with latest patch?

The new Samba vulnerability is exploitable where the attacker has access to a writable SMB share.

So if , for example , you have a home network which doesn't expose port 445/TCP, you're unlikely to be directly affected by this issue.

Also applying all patches for your Operating Ssytems should address this.

One other thing to watch for is that devices such as Network Attached Storage systems can be vulnerable to this issue if they make SMB shares available.


Why do web sites show my iPhone using different IP addresses for HTTP and HTTPS (cellular only)? While testing a recent adtech integration I noticed something I can't explain. The iPhone uses two IP addresses. Seemingly one for HTTP and one for HTTPS. To further confuse things it only happens when the device is not on wifi. Although, the only carrier I've confirmed it happening with is AT&T. FWIW, this does not happen with Verizon

Can anyone explain why this would be the case?

Example:
http://ipof.in/json returns a different IP address than https://ipof.in/json. They appear to be owned by the same carrier (AT&T), as well as both public, but are wildly different (107.77.212.XXX vs 166.216.157.XXX).

It's also worth noting that the response from ipof.in contains a timestamp. Nothing is being cached. I receive similar results with similar service www.ip4.com, etc.

I am just going to take a guess here.  Your telephone data carrier may have an optimizing or caching proxy for content whose IP address appears in your JSON result.  As the proxy has no visibility into encrypted HTTPS packets, it cannot proxy the content, so it may be routing directly with your public (routable) IP address.

If this is the case, your phone has one IP address but the carrier's routing shows different origin IP addresses at ipof.in.


Chrome Frame is an example of how browsers "merge together". How can I unmerge all of them? Chrome Frame is an add in that integrates with IE and Firefox.  Firefox has a similar component, and I hear that the .NET runtime finds its way into all the other browsers.

Additional integration points include:

Protocol Handlers (firefoxurl, cf)
Plugins like Chrome Frame

This integration greatly widens my surface area of attack.  I would like to still run multiple browers, but keep them completely isolated from each other.

How can I "unmerge" (for lack of a better word) all the browsers that I've installed?  I'm not limited to just Chrome here (though I'm using this as an example).

What other integration points can browsers use? Namely Chrome, Firefox, Safari, IE, Opera?

How can I "unmerge" (for lack of a better word) all the browsers that I've installed? In other words, I don't want Chrome vulnerabilities to exist while I browse using IE.

Vulnerabilities in Google Chrome are not directly affecting Microsoft's Internet Explorer.


CAS protection against CSRF attacks A website based on Apache Struts uses central authentication service (cas) for login. I'd like to know if additional csrf protection needs to be provided with Struts in case cas doesn't provide that.

Also, when credentials are submitted, cas generates a token in URL form. If I copy this URL and use it later, the user is authenticated and redirected to the home page.

As I'm not logging in, but just using the token URL, why is this happening? Is this a security vulnerability?

This is old, but must...get...internet...points...

Maybe you're just referring to CSRF protection on the login page, but if you mean in general:

I'm still new to the CAS protocol, but my understanding is that the only time validation happens is at the beginning before you have a session id in the service application itself. Once this is generated, no more contact with the CAS server is needed and no service ticket is needed, so CAS's ST cannot protect you from CSRF attacks.

See:
https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol.html

I imagine the token you mention is the "ST" (service ticket) parameter. Again, new to this stuff, but it sounds to me like you shouldn't be able to use that more than once, so maybe that is/was a bug, or maybe the spec has changed:

https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html#311-service-ticket-properties

However, if you still have your session cookie, you don't need the ST, so maybe that was producing that behavior.


URL query string params Django security I am new to Django and I am working on a website, where you can filter some articles using a normal GET url query string param. Theese params can be made from some input fields. I have found two different ways to approach this, but I am concerned about the security. Which one of theese methods is most secure thinking about vulnerabilities like xss and csrf or some scary characters in the URL?

The first option is to use javascript to collect and add the values from the input fields to a string, and then use the javascript function "window.location.href" to change the clients URL. I am not using any form here. At the server side at views.py:

class IndexView(generic.ListView):
template_name = 'index.html'
model = Articles

def get_context_data(self, **kwargs):
    if self.request.method == 'GET':
        context = super().get_context_data(**kwargs)
        queryObj={}
        category = self.request.GET.get('category')
        if category:
            queryObj["category"] = category
            #adds params to a dictionary if true

        sub_category = self.request.GET.get('sub_category')
        if sub_category:
            queryObj["sub_category"] = sub_category

        context['adrticleList']=Articles.objects.filter(**queryObj)

        return context

The other solution I can think of is to make a Django form with a GET action. This way a can validate the request and protect the client with Django's built in template tags like {% csrf_token %}.

Since it is just GET requests and I am not excpecting users to submit sensitive data, is it really something to worry about?

And if I use forms, the class based view can be a litle bit complex since I am quite new, so can I use function based views, or does this increase the chance for security mistakes?

I am also planning to implement an ajax request to make some dependent dynamically select boxes.

Thanks for thoughts and advices.

If you don't need CSRF protection because the request is idempotent then you don't need a CSRF token.

Reading request.GET in the view, with or without a form, does not affect security.

Using function based views or class based views does not affect security.

I believe simplicity is good, so I would recommend to always use function based views because they are simpler to reason about.

Using a form to validate query params is a matter of convenience. If you need to write a validator, if it's more organized to write it as a custom FormField or as def clean of a form (logic concerning multiple fields at once) then you should use a form. If you validate the same kind of data in multiple places, it makes sense to use a form for the Do not Repeat Yourself principle.


Picking an encryption algorithm for auth tokens passed via AJAX I'm looking for a low CPU intensive encryption algorithm, to pass around session authentication tokens.

As an example:

The user will login in to the website (via OAuth, whether by the site as provider or an external provider)
Regardless of how they were originally authenticated, a new, randomly produced session token (in this case a 64 character length string) is associated with their account and is stored in a cookie.
On each new page request, the session token is taken from the cookie, encrypted with a time-based nonce (to prevent replay) and placed in the headers as a meta tag and rendered.
The user does something which fires off an javascript AJAX request to the site's API. The javascript picks up the encrypted token from the meta tag.
The API receives the params, takes out the encrypted info and decrypts it.
Stuff happens…

Obviously, this could end up in a lot of encryption. Granted, the data will only be small, but it's the volume that worries me. To that end I'm looking for an encryption algorithm that:

Is low on the CPU use
Widely available would be nice.
Easy to use would be nice.

I've had a look around, but the detail of some of the comparisons I've seen is beyond my knowledge to be entirely helpful. If anyone could give a suggestion, that would be helpful. Also, if anyone sees a glaring hole with the security in the above example, please let me know.

Extra info due to the comments:

SSL would be used for all communication.
The (whole) cookie is encrypted using AES. The specific key value pairs are not.
I don't wish to manipulate the value using the browser, I want the already encrypted value to be sent via AJAX and then decrypted server side in the data API.
I don't wish the user themselves to have access to an unencrypted session token.
Most state is kept in the database, the session token is just there to let the API know who's making requests. Barely anything else is kept client side.

The main reason for this kind of set up is to allow many different clients to access the API via HTTPS, whether it's web or mobile or whatever, so the data API server may not reside on the same box as the website, and the website has no direct access to the database.

Your use case is a bit strange. As a basic rule, you need SSL if the data you exchange between the server and the Ajax client is sensitive in any way; you need it both for confidentiality and for integrity. And if you have SSL, then you have all that you need; in particular, you defeat replay attacks (that's a feature of SSL).

You would have to fiddle with encryption only if you want to offload some of your storage on the client; that is, you maintain some user-specific state but do not want to pay for the corresponding database. Instead, you send that state to the client itself, to be stored either in a cookie or in the entrails of the RAM objects maintained by the Ajax code. In that specific scenario, the client is a potential attacker, and you want that storage to be protected with both encryption and integrity, and with an additional time stamp or counter. That's still a rather edge case and it is hard to get right; it is much easier to simply store the user state in the server's database.


Is phone number verifications with SMS magic HTTP links less secure than OTP? I want to verify phone number ownership with specially crafted and encrypted payload within an HTTP hyperlink callback through SMS as opposed to sending an SMS OTP code and writing it back in server web page. The payload will contain validity and expiry, random numbers, etc.
I wasn't able to find anyone using this or similar method except for advertising purposes.
Am I hitting some obvious vulnerability that I'm not aware of?

Your proposal is to effectively use an SMS OTP code - but make it much longer than usual.
Your longer OTP code would be more resistant to brute force guessing, but there are better ways to counteract the problem of brute force attacks, for example:

Make the OTP code expire after a few minutes (and send the user a new one)
Invalidate the OTP code if the user types in the wrong code too many times (e.g. 3 times)
If the user account sees too many OTP input attempts, lock it out for a while

SMS OTP is now looked down upon because SMS has many security weaknesses. The SMS message could be intercepted by someone else (using a SIM swap attack, or some sort of interception while the message is in transit), and if that happens, the longer URL-based OTP code won't offer any additional security.
Usability is the final issue - some people won't want to open the link on their phone (e.g. if they are logging in on a computer). Their phone might not even have a working web browser, or connection to the internet. A short code that they can type in to any device is more convenient.


Iframe hack / done through FTP? On two websites which I host for a friend, I found that there is an iframe at the bottom of each site's index.htm file.

<iframe src="http://www.kunstsalen.dk" width=1 height=1
style="visibility: hidden; position: absolute;"></iframe>

This isn't something that should be on his home pages. It is causing a security warning to show up in browsers which says that his website is a virus/infected site. How did this get there? He has FTP access and both files changed on 11/5/2011 at about the same time. Could he have a virus which changed his local index.htm files and he uploaded them unknowingly? Could a virus use his saved FTP information to log in and change the files without him knowing?

The reason I am assume it originated from his machine is because I have over 500 other index.htm files on my server and none of them were affected. Only the two index.htm files which are accessible through his FTP account.

There can be several scenarios (hard to tell without knowing more).

Your friends FTP credentials were stolen and someone logged in and uploaded modified versions of these files. This can be a keylogger on one his computers (as an example)
Your friends' other credentials were stolen (e-mail?) and were used to gain access to the web site. This can be access to the management console and/of SSH.
Your friends' provider was hacked and there were several customers affected
You friend has a virus on his computer that modifies specific files (e.g. *.php) by appending this iframe.

etc


Could a malicious JS file pointed on URL/URI attack the browser/computer? I found some website blacklisted on Google. I mean when you try to visit them, you get something like shown on this picture:

After a small search, I found that some of them have a malicious JavaScript file on few of their URLs.

My question: could a malicious JavaScript file (pointed on a URL www.example.com/pictures/malicious.js) harm the browser/computer in any way? I mean, could it be executed by the browser? Are there known attacks of this type?

Yes there are known attacks of this type. The site you are trying to visit is one. That's why your browser is telling you not to visit the page.

Javascript files included on pages are always executed by the browser. That's what Javascript does. Whether or not it has the necessary privileges to do something malicious is where the battle is at. It is unlikely that your browser is going to allow it to do something it shouldn't be able to without your permission. The real problem is that it could prompt you for something and lie about what it is prompting you for tricking you into granting it permission to do something harmful to your system. Tricking you into downloading/running some piece of local software is the most likely attack vector, but there are certainly others.

If your question is "is this message baloney" or "should I take this message seriously", the answer is plainly the latter. Yes of course there are known attacks of this type, that's why it's warning you that something is the site code looks like one!


Why does productsign use SHA1 instead of SHA256 to sign the pkg? I have an application which is packed into a pkg file using productbuild and then is signed using productsign. However when I run pkgutil --check-signature only the SHA1 signature is shown. I also tried to create a self-signed certificate using the instructions reported here but the problem is still the same. The only difference is that when the Apple certificate is used (Developer ID Installer: ...) all the chain is dumped to the screen but also for the other certificates only the SHA1 signature is shown.

NOTE: Both certificates reports:

  Signature Algorithm: sha256WithRSAEncryption

So it seems like the certificates are SHA256 capable.
I downloaded another pkg which is signed with SHA2 (the pkgutil tool shows the SHA2 signature). However I don't know what tool is used to produce that package.

If the pkgutil is right and the there are no SHA256 signature in the package, how can I force productsign to use both signatures or only the SHA256 one ?

Are there alternatives to productsign ?

The problem is not how to sign the package but to you check for the signature. It turned out to be a kind of bug of the pkgutil tool which only shows the SHA256 signature on macOS 10.15 (Catalina) while on macOS 10.14 (Mojave) the same tool for the same package only shows the SHA1 signature.

So even if the signature was present it wasn't shown by pkgutil.
Furthermore in this blog the author suggest to use spctl -a -vv -t install package.pkg to validate a package because spctl can also check for notarization.


if the hypervisor is hacked are all guests affected as well? I'm guessing that all guests would be screwed, if the hypervisor is hacked. I found this article, but it seems to be more focused on privilege escalation of guests. I'm more interested to hear about other exploits on hypervisor managers. Many providers use VM control panels like SolusVM. Wouldn't it mean that a security vulnerability in the admin control panel would allow getting control of an array of machines?

Simple answer is yes. If an attacker controls the hypervisor they can potentially get access to everything within it, including the memory space of a VM (which could include keys)

Worst case is to assume all may be lost if the hypervisor is compromised, so in order to prevent this, a well structured, layered security architecture may make it incredibly difficult for an attacker to exploit the vulnerability.

One of the reasons we always encourage defence in depth!


Should a GPG private key always be strictly protected? tldr: should the level of security measures applied to a GPG private key depend on the use case, or should it always be kept strictly protected?
I started using GPG a few years ago, I'm reasonably comfortable with the technical part but I'm still a bit confused about the broader security philosophy.
I use GPG mostly to encrypt my data and my passwords (with pass). I don't really use the signing feature since I don't have any need for it. Neither my data or my passwords are especially sensitive: of course it would be really annoying for me if somebody accessed all my passwords, but I doubt my data/passwords are valuable enough for anybody to go through the effort of cracking the encryption.
My private key is protected with a strong passphrase and stored in my laptop. I would easily let a friend or relative use my laptop for instance, but (1) I trust them and (2) they wouldn't even know where to look for the key. I'm now considering putting it also on my work computer for convenience. In theory this implies several risks: somebody could hack into the network and crack my password, and it would be even easier for an evil system administrator to access it. However these scenarios are quite unlikely in the first place, and the attacker would still have to crack the passphrase.
To sum up, I'm not really strict about the security of my private key for convenience reasons and because I think that the risk of somebody going through the trouble of stealing my key is very low. I assume that paranoid-level measures to protect one's private key apply to people who have much more to lose and/or are more likely targets than me.
Is my reasoning correct or am I being careless?
In other words, should the level of security measures applied to a GPG private key depend on the use case, or should it always be kept strictly protected?

To me, this is less about the protection of the GPG key, but the protection of every account and service that you use.
Putting any kind of personal or non-work data on a work-issued device is inherently risky. You do not necessarily know who has remote access into the device, where or how backups are taken and stored, who has access to those backups, who has access to network traffic that may flow through a VPN, and more.
Putting your private keys on such a device means that you are likely going to be using those passwords to access services. In the worst possible case, not only would your private key be compromised, but all of your passwords would be, along with anything stored locally on the work-issued computer and possibly even network traffic.
Everything does depend on the threats that you are trying to mitigate. However, putting a private key out in the wild seems like a generally bad idea, even with a strong passphrase. Even if nothing bad necessarily happened to your passwords, there are good reasons to keep your personal stuff as isolated from your work stuff as possible that aren't directly security-related.


someone is trying to SQL injection me.. what are they trying to do? I get a lot of logs saying someone is trying to reach

/sign_in?t=login'+union+select+char(38,126,33),char(38,126,33),char(38,126,33),char(38,126,33),char(38,126,33),char(38,126,33),char(38,126,33),char(38,126,33),char(38,126,33),char(38,126,33),char(38,126,33)+--+

now, /sign_in?t=login is a valid url. the rest is the sqli attempt..

What are they trying to do?

This looks like a fully automatic attack which is performed by bots on random websites they find.

The attack is trying to get your database to output the string &~! (ASCII values 38, 126 and 33). They likely parse your websites response for that string and when they find it, the bot assumes that it was the result of its injection and reports it to a human cracker as a potential target for a more targeted attack. The cracker will then take a look at your site and consider if the data you have might be worth their time. Only when you appear to be a lucrative target will they pursue further actions.

Did you take the usual precautions to secure your website against SQL injections? Then you have nothing to worry about.


Can my company see what HTTPS sites I went to? At work my company uses internet monitoring software (Websense). I know if I visit a https ssl-encrypted site (such as https://secure.example.com) they can't see what I'm doing on the site since all the traffic is encrypted. But do they see, that I visited https://secure.example.com?

An encrypted connection is established first before any HTTP requests are performed (e.g. GET, POST, HEAD, etc.), but the hostname and port are visible.

There are many other ways to detect which sites you’re visiting as well, for example:

your DNS queries (i.e. they’ll see the IP request for secure.example.com)
via network monitoring (e.g. netflow, IP to IP sessions, sniffing, etc.)
if the device you are working on is owned by the company and they have administrator access/privileges to view anything on the device (e.g. view your browser caches)

A popular way to evade a Websense proxy is to first establish a connection via HTTPS to an outside proxy (e.g. https://proxy.org/) and make your request from there.


PCI Compliance - Encrypted Mobile Apps My company (health care) went through a PCI audit and needs to solve some major issues. Our branches collect CHD on paper and saves them to a network drive as a pdf that our corp office accesses to enter into Paymentech and charge them ongoing everchanging weekly charges. Obviously, that was flagged, mainly for unencrypted transmission via scan to mail email to the desktop where the pdf was then saved on the drive.
The two options discussed were either continue with paper and to encrypt directly from the branch's copy scanner and save to a secure server directly or to use a mobile ipad app that encrypts the CHD that is properly keyed (not swiped) into the app and send it to our secure servers.
I haven't found any copy scanner with encryption option nor have I found an app that sends encrypted data and removes it from the ipad immediately.

Any ideas on on how to secure this CHD via option 1 or 2 or your own? Thanks

***To CntrlDot - You are right, another big problem is the need to retain the CHD that is collected in the field before the charges are created. Plus the credit card is sometimes not present and CHD is given over the phone to the sales rep. So the swipe option won't cover what we do. I just found out we are locked into Xerox scanners, which I cannot find any immediate encryption option. Still looking at using the ipad option which removes the paper from floating around, but can't find an app the encrypts, sends and then removes. Thanks for any answers.

My advice to you is, rip off the band-aid and go modern.

It's hard to judge without knowing more about your situation (who's collecting the CHD?  What environment?  In an office?  On the phone?  On the street?).  But the easiest way to make it all go away is to go for mobile-device based swipies that will encrypt before the info hits your device and send it on in.  If you never have unencrypted card data, you don't have to worry as much, and you have less PCI scope.

I'm aware of Roam and Square that do this off the top of my head, and there are other companies out there doing the same.  Enabling the mobile device is the new black.

Could you add compensating controls to ease your existing solution?  Sure.  Google quickly shows me that Ricoh has a device whose scanner can

  Protect sensitive or confidential scanned documents with security
  features, including encrypted PDF transmission.

Some doco for that here.

But it sounds like you've got some jury-rigged methods in place, and that's what's drawn the auditors (well, that and the lack of encryption).  If you jury rig controls on top of a jury rigged solution you're not doing yourself any favors.


Using a password hash...as the password? Ok, this is probably a really stupid idea, but I can't really see why it would be a bad idea.  Maybe someone can enlighten me.

Why couldn't you enter a password good hashing algorithm like bcrypt, and then use the hash itself as your password for the website?

Because of the Avalanche Effect, this could allow users to use subtle derivations of their regular password to create competently different (and possibly better) passwords to use on actual websites.

For example, let's say a users password is "password123", and they want to log into a few different sites, so they append the sites name to the beginning of their password like so:

Amazon.com="amazonpassword123"

Facebook.com="facebookpassword123"

And so on.....

Normally, this would be very bad practice, as it would be trivial for an attacker to guess this user's naming system for passwords.  But if the user ran his passwords through a hashing algorithim BEFORE logging into these websites, and then using the hash itself as the password, we have something that is very easy to remember and (possibly) more secure.

Is there any disadvantage I'm not seeing to this?

Nope. It's a great idea. The trick is getting those hashes into different sites' length and complexity requirements.

PwdHash is one great example. It uses HMAC-MD5, but it drops so many bits from the output it's probably fine. (That's a technical term. Besides, MD5 pre-image resistance is still unbroken.) More importantly, they solved the problem of length and complexity requirements nicely, and there's working software for it on many different platforms (Firefox, Chrome, Mac OS, iOS, Android, the website itself).

Master Password is another app, which uses HMAC-SHA-256, but is only available on Mac and iOS. Also, it is a bit wonky in its encoding technique. Its defaults are way too low-entropy because they try to be "pronouncable" by controlling vowel positions. I submitted a bug report and was told that entropy is irrelevant and to go soak my head. It's fine if you use the paranoid setting for serialization, but it's too much of a headache compared to PwdHash for me.

It's a bit sad that this is the state of the art in this category, and it's also sad that the PwdHash people didn't just use scrypt.


Physical Security for USB Keys and Systems-on-a-Stick Do there exist physical security devices for USB sticks that serve a function analogous to laptop locks (i.e. preventing smash-and-grab type attacks)?

If so, what are they and to what extent do they offer protection?

Example scenario: I plug a $250 USB SSD key into my laptop and work in a coffee shop. The attacker yanks out the key on their way out the door and starts running. Even if my data is encrypted, I'm out $250 + any data since my last backup.

The problem with most USB thumb drives is that they stick out a whole lot, but you can buy smaller USB drives that will fit snug against your laptop. The problem is that obviously they will be much smaller capacity, but you'll get that security.

Something like this:

Additionally, since most laptops have this feature anyway, you could use a SD card, since that will fit right into your laptop, not exposing itself at all. A potential thief/attacker would have no idea it's even there unless they nabbed your laptop.


Securing Data at Rest in Android Here's a situation.

I am the author of an app that allows my customers to stream videos on their local android device. I also allow them to download the video and store it locally on their android device itself.

But now I want to restrict the distribution of the downloaded video somehow. I want to ensure that the downloaded video can not be simply distributed to another user, who is not even registered with my app.

How can I achieve this ?

Some solutions that I could think of :

Encrypting the video with a key that's bound to my registration ID. The problem is that the key will need to be stored on the device itself. And if the device is rooted/compromised the key can be retrieved.
Making an auth request before every time the video is allowed to be played locally. The problem is that is defeats the intended purpose of the offline playing of the video. Hence, not something very desirable.

You've answered the question yourself. You're trying to implement DRM to prevent users from getting the video off the device. In practice there is little you can do to prevent this. There will always be ways to copy the stream, even intercepting the stream (it has to be displayed on the device at some point right?).

So the only thing you can do is make it harder, but not impossible to copy it. You can also include some meta data to the video when streaming or when downloaded to identify the user which leaked the video.


keytool -importkeystore gives error when using openssl pkcs12 -export with -passout pass:mypw option I'm running openssl pkcs12 -export with -passout pass:123 for automation purpose (without prompt for pw), then using keytool -importkeystore to generate keystore.jks. It failed to decrypt password with "pass:mypw" option, running openssl export without -passout pass:123 works just fine. But I really need the -passout pass:mypw for automation purpose without being prompt for pw.

% openssl pkcs12 -export -out keystore.pkcs12 -in mydomain.com_cert.pem \
  -inkey mydomain.com_key.pem -passout pass:123

% keytool -v -importkeystore -srckeystore keystore.pkcs12 -srcstoretype PKCS12 \
  -destkeystore keystore.jks -deststoretype JKS -deststorepass pass:123 \
  -srcstorepass pass:123

Am I missing something here?

openssl command:
I don't see anything wrong, so you have the PKCS12, but you can’t convert it to JKS.

keytool command:
You don’t put pass: before the PASSWORD like in OpenSSL.
keytool -v -importkeystore -srckeystore keystore.pkcs12 -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS -deststorepass 12345678 -srcstorepass 12345678


Why not use a private CA? I had a question when reading this article:

Phony certificates fool faulty crypto in apps from AIM, Chase, and more

(Basically, some Android apps, like Chase's banking app for example, may be ignoring certificate validation errors, possibly because the app is trying to accommodate outdated CA lists on older devices and Android versions.)

In the context of this sort of banking app, why wouldn't the developer use a private CA instead of signing the server (and, for that matter, client) certificates through one of the public CAs?  The developer controls both ends of the transaction, after all.  Am I missing something, beyond laziness?

The issues which are talked about in the article are mostly of the following kind: the applications misuse the protocol, in that they disregard validation errors. They do so because the application developers use SSL as a black box which is just assumed to "add security" by virtue of being there. These developers are not helped at all by the state of the documentation of many SSL libraries, which, when it exists at all, is rarely clear for anybody who has not studied X.509 certificate validation.

Someone who would use his own CA would be someone who is aware of the issue and understands what is going on when a certificate is used. That is the solution: that application designer would not make the mistakes to which the article alludes. A private CA is just the logical solution towards which application designers steer when they know what they are doing. Maintaining a private CA can be complex and expensive, but that's a symptom of certification being, generally speaking, a hard problem. The important point is that application designers must grasp what SSL and certificates do and do not. As long as they do not, no amount of private CA will save them.


A protocol for encrypting the data on the server, but with a password on a mobile device I want to implement the following encryption scheme. The data is created and stored on a web server, but related to some user of the system (i.e. it is entered "on behalf" of the user). Both encryption and decryption process should involve a request to a mobile device of this user (the encryption password is located on the device). The point is that nobody, including the server, would be able to approve the encrypted data entry on behalf of the user or later decrypt it without having access to a mobile device of the user.

However, we can’t send the whole data to the device for encryption, because (aside from the matters of security) it could be very large. Also, the decryption is done to provide access to some third party, so there's no need to transfer the data to the device at all. So both encryption and decryption should occur on the server.

Another point is that the encryption/decryption occurs on a per-record basis, so it would be preferable that noone (even the server) at any point in time would be able to decrypt all user data at once.

I need to come up with a protocol or a pattern to do this.

As a precondition, the server already has an ID of the user’s device. This allows the server to send a push notification to the device. The push notification channel is secure in the sense that it is over TLS. However, there is a risk that the messages are stored as plaintext somewhere in the push notification provider database and could leak in the case of a data breach.

I was thinking about the following protocol (for the encryption):

the server generates a one-time key (OTK) and a transaction id (TID)
the server sends a push notification to the device containing the TID
the device sends the TID to the server via HTTPS, receives the plain-text OTK in response
the device encrypts the plain-text OTK with a password known only to the device and "forgets" the plain-text OTK
the device sends the encrypted OTK and the TID via HTTPS to the server
the server uses some symmetric encryption algorithm to encrypt the data with the plain-text OTK, and then "forgets" the plain-text OTK
the server stores the encrypted data together with the encrypted OTK

For the decryption, the protocol is similar.

So my questions are:

Is this approach reasonably secure (by "reasonably" I mean at least
as secure as other involved protocols, like OTK generation,
HTTPS and some chosen symmetric encryption protocol used on the
server)?
Are there any other patterns to do something like this?
Are there any known implementations of these patterns (for any kind of backend, any kind of a mobile device)?

Before designing a protocol, we need to make an important decision: do we trust the server?

If we do, the design can be quite simple: HTTPS would be used for communication encryption, and disk encryption would be used for data encryption, and there would be no encryption in application code. All access control decisions like "is this data approved" and "is this third-party authorised" would be done as database records, enforced by checks in application code.

This is the standard approach, used by many thousands of client-server applications, including high-value finance, military, aerospace and healthcare.

In some cases, it is possible to avoid trusting the server. For example, many password managers encrypt your password vault with a master password on the client, and the server only processes the encrypted vault. However, this gets harder with more complex applications, especially when multiple parties are involved. There is a major risk that a scheme will only add the appearance of security, not true resistance to attack.

For example, in the scheme you propose, the server has transient access to the one-time keys. So a hacker (or malicious sys-admin) could harvest data over a period of time. To rectify that I recommend using public-key encryption:

Each user of the system would have a private key that only they know, and a public key that is shared with the server and other users.
When a third-party creates a record, they encrypt it with a random key (like the OTK), and encrypt the OTK with the recipient's public key. The server stores this in a temporary area until it is approved.
A user approves a record by signing a hash of it with their private key. The server then puts the encrypted & signed message in the database.
To share a record with a third party, the user encrypts the OTK with the third-party's public key.

Even with all this, the server can potentially cheat by substituting a user's public key with its own. You can partially mitigate that with external monitoring, or an external certificate authority. Ultimately, this is a great increase in complexity for what is probably just a marginal benefit. That's why the standard pattern is to just trust the server.


How to secure a domain name from insider threats, domain hijacking in a corperate context? Usually there's just one e-mail / e-mail password / domain registrar username / password. And perhaps one 2FA (google authenticator) device and a 2FA recovery code.

Either an employee has access to these credentials or not. Each employee has access to these credentials, can hijack the domain, i.e. transfer it to a different registrar.

How to secure domains from malicious domain admin employees?

Is there something like "multisig" (a term from the crypto currency world) where two of three people or 3 of 5 etc. (depending on company size) need to authorize domain related changes?

The best thing you can do is choose a registrar with a good track record of taking security seriously.

Registrars sometimes offer the ability to have multiple user accounts which can administrate the domain. This is important because you wouldn't want to be locked out if someone quits and doesn't give you the current password, or if the email associated with the account is linked to that employee.

Certain registrars will also allow out of band verification before changes are allowed. E.g. they call you to confirm changes.

CloudFlare registrar has a good rundown of some good registrar protections https://www.cloudflare.com/products/registrar/custom-domain-protection/

Your domain security depends heavily on your registrars policies and security.


Unclear security impact of a Reflected XSS vulnerability What is the security impact of a Reflected XSS vulnerability on a state website involved in financial relations? There are no user profiles on this page and it serves as an information board and a place to download project applications.

... no user profiles on this page

XSS (including reflected XSS) can basically do everything inside the site what the user with a browser can do. If there are no user profiles it can at least not impersonate any users. Note though that if there are users on the same domain or subdomain, then XSS might use existing session cookies to impersonate the logged in user and do actions in the name of the user, no matter if these specific actions are actually included in the specific page vulnerable to reflected XSS.

... serves as an information board and a place to download project applications

XSS might also completely change the appearance of the site. And it can also change things which are not obvious, like changing the values in the shown financial information or make the download links point to malicious downloads instead. Note that these changes are only temporary in the rendered page, i.e. no server side changes are done. But if there is a way to edit such information it might be done using XSS too.


REST security using only API key and SSL I am looking to build a number of simple REST web services where:

they only need to be called by server-side clients (i.e. no mobile/javascript/desktop)
they are only accessible by HTTPS (no downgrade to HTTP)
clients will only be deployed to secure, trusted locations
clients will each have a unique API key
each service will hold a list of permitted client keys

When accessing a web service, a client will provide it's unique client key in each request body for authentication to that service.

Question: Is this simple approach sufficient to restrict access to the services to only known clients?

So in principal if you have a situation where it's server-to-server communication then some of the standard concerns about user authentication aren't in play and what you've got sounds reasonable, some things to think about though (and whether these are relvant will depend a lot on your threat model)

Do the API keys used have sufficient entropy to prevent guessing or brute-forcing attacks?
Do you have a process in place for key revokation/re-issue in the event that one of the clients security is compromised.
Are you using Certificate pinning or something similar to mitigate the risks of client machines suffering a MITM attack, where the attacker has the ability to issue a cert from a "trusted" CA.
Does the process for loading the keys onto the clients and servers mitigate the risk of a participant in the process copying/abusing the key?
How are you storing the keys server-side?  In the clear, in reversibly encrypted format, or in a hashed format?


Preventing remote control "attacks" on televisions, projectors, and set-top boxes During lunchtime, I watched as a friend attempted to discreetly turn on a television in a public place and flip through the channels using his phone's infrared transmitter (although rather stupidly, since the television was not actually connected by coaxial to a source).

Although he was not caught, I wondered if there was any way to prevent such attacks if a television or projector was used in a large venue. Taking control simply by looking at the brand and model is a serious vulnerability: anyone with widely available hardware and software can mute audio, turn off a projector, change inputs (such as with a network projector, in preparation to take video control of it as well), and the like. The vulnerability is also present in common set-top boxes (which can be used to, for instance, change the channels at a sports bar).

Are there any practical remedies to this problem? Taping the IR receiver on the devices prevents legitimate use of a remote control, and devices that already use IR cannot simply be retrofitted with RF.

Consumer IR is inherently insecure. And the reasoning for this is quite simple, why shouldn't it be?

Risk Assessment wise:

Can it be easily resolved?
What's the harm done?
What are the costs involved?

Some venues do in fact use flat panels that don't have IR on the front. There's no reason to have it, as there are physical controls. But let's propose that there are no IR control capabilities, then what stops someone from walking up and "changing the channel"? If the need arises, just tape over the IR port, and mount the display out of reach.

Does changing a channel really drastically impact people? Not really, so why would I invest in some high tech solution to prevent people from doing so? Tape and a monitor/tv arm solves the problem quite easily.

Most remote controls you receive for "top boxes", or "cable boxes" have the ability to self program, so the end user only needs 1 control for all their devices. It does this by systematically scanning and trying different codes until the TV or such device turns off. Lists of these codes are public, and can be programmed into a device. There is typically a grouping of codes per a brand (LG, Samsung, etc.).


What can I do if I discover that my password hash has been leaked in pastebin? Entering my email at https://haveibeenpwned.com/, I was told that I have been pwned. I am in http://pastebin.com/SCLNRHJQ

I already tried

to find out my password by simply md5-hashing all my passwords I could think off and comparing them to the hash in pass
to check whether someone could easily crack my password by putting the hash into some online md5 "rainbow table service" myself.
to find the breached web site by searching my mail for registration notifications received on the registration date given in joined_on
to find email received from any mail address in the list.
to send an email to the first in the list, asking him whether he knows which site it is and/or whether he possibly is the owner of that site.

All of these loose ends came up blank.

I could only deduce that it has to be a really small LEGO-themed website, but that's it.

So I have changed all my passwords of my most-used accounts, especially the email accounts. The many old and sleeping accounts I don't know that I have, they are out of reach.

What else can I do?

The first rule is to clean up your act: use a password manager and have unique, long and random password for EACH and ALL your important services (email, google, etc.) and change all your passwords.

Then check if there are some mysterious transactions made on your accounts (not specifically bank accounts, mind you: anything that could be accessed using the email that was compromised). That should give you a good indication if the possible risk of being breached was realized.

Finally, take each possibly compromised account and think of how it could lead to a continuing issue: could some information extracted from that account be used in the future ? If yes, is there any action you might take to reduce the consequences ? Is the risk you're running worth the price you're going to pay to mitigate it ? If you can't mitigate it, can you ensure it ? Is it even worth insuring ?


Can I say that my web app is HIPAA compliant? My team and I created a web app that transfers data from a VOIP system (recorded calls, voicemails, faxes, texts) to cloud storage (Google Drive, Amazon S3, Box.com). In and of itself, our app follows HIPAA guidelines. I have a background in medical software, and have created several medical apps that meet HIPAA requirements for data storage and data transfer. And I made sure we did the same with this app.

But I ask this question because this app is just a bridge. This app stores very little data. (And the data we do store is encrypted and protected). The real content of the phone systems data is stored in our customers' own storage (their Google Drive, their Amazon account, etc) after our app transfers it. Of course our app has access points to their storage, but we have ensured that the access we provide is protected and HIPAA compliant from our side.

My concern is our reliance on these third party providers. Even our login procedure piggy-backs onto third-party VOIP providers for authentication. The VOIP provider does state that they are HIPAA compliant, however.

Just for clarification, we are using OAuth to provide authentication (via the VOIP's authentication api), and we are using OAuth to provide a connector to Google Drive and Box.com. Amazon does not provide an OAuth api, but the process is similar using security tokens via their Amazon S3 api and federated login control panel.

I know that we have done all we can to make our app HIPAA compliant (short of storing their data in our own system), but with all the reliance we have on these third party providers, can I accurately state that we are HIPAA compliant?

Well no - you get a third party to audit your controls and they sign off and say you are HIPAA compliant. Its the whole seperation of duties thing your company builds it and a independant trustworthy third party confirms the work you have done.