How can PrivateSky not see your data? PrivateSky is a website that promises encrypted "cloud-like" secure information exchange. They promise that except the sender and receiver, nobody can see your data. After testing it yesterday, I do not understand how this is possible.

Let me explain you step by step what I did. Assume I have two email addresses A and B. I want to send an encrypted message from A to B. So I proceeded as follows:

I created a PrivateSky account for my email address A.
I clicked on the link I received on A, to confirm my email address.
Back on PrivateSky, I created a PIN for A.
Logged in as A on PrivateSky, I send an encrypted message B (without first  creating a PrivateSky account for B).
I created a PrivateSky account for my email address B.
I clicked on the link I received on B, to confirm my email address.
Back on PrivateSky, I created a PIN for B.
My message from A appeared in the "Inbox" on B's PrivateSky account.

Again, how can they not see my data? There is no information that I sent directly from A to B, all communication went through PrivateSky. Also, B "received" the message before creating a PrivateSky account, so how could the encryption key be securely transmitted from A to B?

This is Brian Spector; I'm the CEO of CertiVox.
Thanks for starting this discussion on PrivateSky, our secure information exchange service.  I’ll do my best to answer the intelligent comments and criticisms on this thread.
Second, I’ll try my best to walk the reader through step by step on how our integrated key management and two factor authentication works.
I invite the folks on this thread who haven’t read the white paper to please do so.  Everything I am writing has already been written in detail and is publicly available in that document on our website.  But since no one reads white papers….
First, let’s refute the statement that we are "lying".  We are not, and indeed, we are trying to be as transparent as possible about how we do what we do.   It’s hard to argue with that kind of blanket statement, so rather than go there (“so Mr. Jones, when did you stop beating your wife?”), let’s just go through the intelligent points on this thread, as there are quite a few.
To that end, that’s also why we open source our MIRACL SDK, freely available off of our website.  MIRACL powers PrivateSky, and the same cryptographic processes in use in PrivateSky are available as libraries in the MIRACL SDK, so you can review the code.  MIRACL is in use by hundreds of companies around the globe, and has a fairly decent reputation as having very fast elliptic curve cryptography optimized for constrained environments.   It is trusted by many organizations. We take that trust extremely seriously; it’s our bread and butter.
To correct Lucas’ statement here:

Probably the simple answer is: it's not.
If I read correctly they just seem to have used a form of symmetric encryption to authenticate yourself to the system after which you can access your private keys to encrypt data (the private keys are encrypted with your pin).

That’s not correct.  Let’s clear up that one up first.  The SkyPin you see that logs you into PrivateSky with your email address and 4 digit pin is an elliptic curve authenticated key agreement protocol that uses two factors of authentication, based upon an IEEE P1636.3 draft standard, Wang’s protocol, with the addition of our chief cryptographer, Dr. Michael Scott’s protocol for remote login with simple token and 4 digit pin using elliptic curve bilinear pairings.
Note that Mike’s protocol has been peer reviewed extensively since its first publication in 2002, has withstood over a decade of cryptanalysis, and we’ve published an updated version, this time adapted for use with Wang’s protocol.
Of the two factors, the first factor is a mathematical token stored in your browser, locked to the domain of our authentication service, the second factor being your pin.  It work’s like this: The SkyPin Pad you use is actually performing a reconstitution of an identity based encryption key issued in the ID of your email address, we issue this to you when you register.  During the registration process, the SkyPin Pad performs a equation on the IBE key you were issued using the 4 digits you select.  This process is performed locally.  We don’t know what those 4 digits are.  At that point, it becomes what we call a “token”.  The token is stored in your browser’s HTML5 local storage, not session storage (i.e., not a cookie).  This is locked to our authentication service’s domain.
The next time you login, the SkyPin Pad is served from our web server (over TLS, domain secured by DNSSEC) and runs locally in your browser.  The SkyPin Pad takes as input your 4 digits, reverses the equation, reconstituting the identity based encryption key you were issued when you registered, again, performed locally.  This is Scott’s protocol.  The next step is an authenticated key agreement protocol based upon Wang’s protocol, whereby encrypted nonces are exchanged with the IDs of the server and individual attempting to authenticate mutually.  At then end of the protocol, both the server and individual have identified themselves to each other, and each side has at their disposal an AES 128-bit key, the session key.  Hence the term; authenticated key agreement protocol.
So no, this system does not use symmetric keys to authenticate users.  It’s a two-factor authentication system based upon elliptic curve cryptography, running in JavaScript, tailored for HTML5 compatible browsers, that performs authenticated key agreement.
Lucas is also incorrect with this statement (note Lucas that generally you don’t decrypt with public keys, you verify signatures with public keys, you encrypt with public keys):

It still might be decrypted with a the other persons public key browserside. But then again everyone has a public key available, they just need to fetch it from the server and apply it by the browser. – Lucas Kauffman5 hours ago

And by association Rasmus is correct with this statement (thank you for reading the white paper, btw):

According to the white-paper they use SK-KEM, which is an identity-based encryption scheme. This explains why you do not need the public key of B in order to send an encrypted message to him (the email-address is the public key).

In an exponent inversion system like the variant of SK-KEM that we are using, it’s actually a key encapsulation system, whereby the content encryption key is encapsulated (i.e., encrypted) using a protocol with inputs of the global public key of the system and the email address of the recipient.  The message is signed using the ECCSI protocol with the user’s private key issued from our private key generator.  The user employs a different private key issued from our private key generator to decrypt a message, using the SAKKE protocol (a variant of SK-KEM).  The cool thing about SAKKE is that is also has the ability to federate private key generators.  Assuming a user has access to the public parameters of another’s private key generator, user A who has a private key of a PKG A can communicate with user B who has their private key issued from PKG B.
Both ECCSI and SAKKE are part of an IETF informational draft called MIKEY-SAKKE, which is being standardized to provide voice data and encryption over 3G networks.  MIKEY-SAKKE has strict guidelines on the operations of the PKG to cover such nuances as master key rotation (every 30 days) and packet assembly.
Up until recently, it was assumed that you could not distribute the private key generator in an exponent inversion system.  Thankfully, Smart and others devised a multiparty computation protocol that enabled such a possibility.
Developing further on that work, Smart and Geisler published a paper called “Distributing the Key Distribution Centre in Sakai–Kasahara Based Systems.”
Effectively, you could split the PKG into distributed private key generators, or D-PKG’s.  The nice thing about this is that after the initial setup, the master key doesn’t live anywhere in whole; it is split into thirds.  Only two of the three nodes need to be available to server shares of the private key to the intended party.  The master node is taken offline and discarded after setup. Assuming you have built processes by which to do this, shares of private keys in such a system can be created dynamically as they are requested.
Rasmus makes this statement:

Usually identity-based encryption relies on a trusted third party. So their claim that they cannot decrypt the messages themselves is based on their having placed the master private key and the associated private key generator inside what basically amounts to a hardware security module.

And Lucas makes this statement:

Yes, it seems they just put the trust somewhere else. They can't decrypt it their selves, but their claim that no-one else can seems to be false

Rasmus is partially correct, and Lucas is not correct.  It’s actually several hardware security modules, none of them actually possessing the master key in whole.  We take the additional steps: D-PKG nodes into HSMs that are tamper proof, tamper resistant, with integrity verification upon boot up of the VM, and carry no state (other than their share of the master key and the code to distribute shares upon authenticated request).  We cannot access the shares of the D-PKGs without ruining some expensive kit.  But let’s assume we could re-constitute the shares of the PKG.
Because we are following the MIKEY-SAKKE operational guidelines, these D-PKGs are only in operation for one month, meaning, the master key and subsequent private keys issued are only good for one month, and the entire population is rotated every month.
In PrivateSky, the user will be asked to create a unique passphrase.  This is used to create a 32-byte long-lived ECDH private key (and subsequent public key), which can also be used in an ECIES setting.  The ECDH public key of the user is stored in our directory.  The D-PKGs have ECDH key pair that is not long-lived, only monthly. When new keys are issued, a DH secret key between the D-PKG month private key and the ECDH public key of the user is created to encrypt the newly issued ECCSI and SAKKE private keys for the user.  This happens for every user.  These are stored within our directory for the user so they can decrypt old messages outside of the 30-day master key rotation window.
The point being, after the 30-day window where the shares of the master key are in use, the VMs are destroyed, the key material inside the HSMs are wiped, and we start over again.
So let’s outline the general attack scenarios:
Inside the 30 day window, in order for us to decrypt the data (or turn over keys when we are served summons for requests for information):

We need to carefully hack an HSM at FIPS 140-2 Level 3 so as not to destroy the units, twice.  In two different data centers.

Outside of the 30 days window:

We need to crack AES 256 in order to decrypt the archived private keys OR
Someone has to crack AES 128 bit for every single message

You are probably wondering, why in the hell have these guys gone to such great lengths to construct such a system?  Especially in light of this admission:
User 1202236 makes this statement:

Thanks for clarifying. So instead of trusting a software company, now you trust a hardware company and that the software company actually uses the provided hardware. It seems to me that you need to trust quite a few people when compared to PGP.

That’s correct.  Let me ask this is a more direct way:  On a trust scale, is it better to use PGP or PrivateSky if you want to be 100% sure that no one can see your data?  Answer: There is no question that creating your own private key via a system such as PGP is better as a trust model.  No question at all.
There is only one problem.  PGP and the current state of the art are too damn hard for the general population at large to use.  Not the people on this board mind you.  But I mean my daughter, or her friends, or my parents.
In PrivateSky, using a PIN, a passphrase and your email address, we can get you close, with two-factor authentication as a bonus.  And you don’t have to learn anything.  You don’t have to do anything different to use PrivateSky than you would any other web property around.  That’s why we built it.
The people at CertiVox sincerely believe that just because we want to communicate something through the Internet doesn’t give the government, the NSA, Dropbox, Google or any media companies the right to use my family’s information or mine in the largest data mining scam ever perpetrated on the human race.
From a business perspective, our architecture also accomplishes the following:
We will be served with requests for information from authorities. That’s a fact of life when you run a Saas business. Thankfully, in the UK and the EU, there is due process and law for this.  How we comply, and our ability to prove the extent of our compliance, rests with the architecture we develop.  If your data is accessible by us in the clear, then we have to turn it over.  If it’s not, then we still have to turn it over.  But if what we turn over is encrypted, and we don’t possess the keys, then what good is the data (it’s encrypted), and what good is serving a FISMA warrant or EU equivalent on us?  Complying with requests for information is really, really expensive for a young company.  Not being a target for such requests is a competitive edge.
Which leads me to my next point.  The team at CertiVox has made a bet that there is a market for a secure information exchange service where our business model is dependent on NOT seeing your data.  We believe (maybe naively) that there is enough people and organizations out there who are concerned about the erosion of privacy but don’t have the technical expertise to do anything about it.  Dropbox needs to see your data to de-duplicate.  Google needs to see your data to serve you ads.  We don’t do either and never will.
To that end, we will soon introduce the capability for anyone to run your OWN distributed private key generators, and register these on our system (through the SAKKE federation capabilities), completely taking us out of the loop.  You control your own population of users, can rotate master keys at will, revoke users, etc.  That WILL give you the equivalent trust model of PGP.
Lastly, let’s go through the steps of how our integrated key management system works.  We call this Incognito Keys.  You can download an info graphic PDF that is a visual diagram of the following explanation:
To encrypt and sign a message:

Alice logs into PrivateSky with her SkyPin and email address.  The two-factor authenticated key agreement protocol produces an AES 128 bit key for use at the browser end and at the authentication server’s end.
The authentication server passes the AES key to our “black boxes”, the D-PKG nodes.
The D-PKG nodes assemble the shares of Alice’s ECCSI key and encrypt these with the AES key.
Alice receives the encrypted ECCSI key (shares), decrypts the shares with her AES key, assembles the ECCSI key from the shares, and is ready to go.
Alice writes a message to Bob and encrypts the message with an AES key, called the content encryption key.
Alice encapsulates the content encryption key with inputs of the Global Public Key and Bob’s email address and appends the encrypted / encapsulated key to the message.
Alice signs the message with her ECCSI key.

To decrypt and verify a message:

Bob logs into PrivateSky with his SkyPin and email address. The two-factor authenticated key agreement protocol produces an AES 128 bit key for use at the browser end and at the authentication server’s end.
The authentication server passes the AES key to our “black boxes”, the D-PKG nodes.
The D-PKG nodes assemble the shares of Bob’s SAKKE private key and encrypt these with the AES key.
Bob receives the encrypted SAKKE private key (shares), decrypts the shares with his AES session key, assembles the SAKKE private key, and is ready to go.
Bob receives the message in his portal, which contains the encapsulated content encryption key.
Bob verifies Alice’s signature, and de-encapsulates the content encryption key with his SAKKE private key.
Bob uses the content encryption key to decrypt the message.

So there you have it.  You can argue with the math, the implementation or our intentions, but hopefully we have made all three clear.
Thanks for reading all the way through, and please sign up for PrivateSky!  You can see all of this working in action for yourself.
Brian


How are malware able to start on boot on windows without administrator rights? I know that a malware could create a new Run registry key to make itself start at boot, but an user could simply remove the registry key and reboot and that would stop the virus, but this is usually not the case. I know that if a malware has adiminstrative rights it could replace a core windows program to be undetectable and persistent, but what if a malware doesn't have administrative rights? How can it defend against a user that removes its registry key?

How are malware able to start on boot on windows without administrator rights?

Find a Service which runs an executable which a user can overwrite (Hint: Installed software that has its own updater usually fits the bill.)
bitsadmin (see this example) can run on schedule or on event, and call a handler program, specified by a user.

  if a malware doesn't have administrative rights? How can it defend against a user that removes its registry key?

Of course, either of these can be undone by a user just as they can be done by a user, but they're subtler than Run keys and more likely to avoid notice.


Details of a good WPA2 pre-shared key (password)? From the following answer, I understand a strong pre-shared key must be 15 characters at minimum and randomly generated:

https://security.stackexchange.com/a/56646/37051

However, from other reading, I understand that cryptographically strong passphrases can be made with diceware tools such as this one.

An example of a diceware-generated passphrase is:

under-chrome-obedience-navigator-shaping-stability-barracuda

Comparing that to a 15 character random password such as this, which is better as a WPA2 pre-shared key?

z9zaBQj&$#7&Fpg

If the usage was not WPA2, I would pick the diceware passphrase because it is much longer while also being easier to use correctly (memorize, enter, etc.). However, I assume WPA2 may change the decision in some way. So, what is the best WPA2 pre-share key generation method? And how long should it really be?

Contrary to the originally accepted answer, a random multiword passphrase is not subject to what we usually mean when we say "dictionary attack" (that's when you just throw a large wordlist at a hash, one line at a time, maybe with a few rules thrown in). Such a simple attack would have no effect on a solid Diceware passphrase. Your seven-word Diceware-based example above, if truly randomly generated, would be randomly located in a pool of 1.7x10^27 possibilities (we often use "keyspace" as shorthand for this).

This keyspace is roughly the equivalent of a 13-character password randomly generated from the entire 95-character printable ASCII character set. Even if the password hashing method was a very fast hash (such as MD5), a 10^27 password cannot be exhausted simply by renting a few (or a few racks) of GPUs.

If this seems counter-intuitive, I encourage you to do the math. If you calculate how long it would take to exhaust a 10^27 space - see this excellent Jeremi Gosney rant on Twitter - then unless the NSA is after you (in which case, they're not going to bother with your WPA2 passphrase), either of these password methods are more than sufficient ... even if your password is stored using a really fast/bad hash like MD5.

But in this case, we're not talking about MD5. We're talking about WPA2, for which cracking speeds are much slower - for example,  on the order of 2.5 million hashes per second on a 6x 1080 GPU rig. That may sound fast, but again - do the math. Even if you assume capabilities of a trillion passwords per second (nation-state grade, which would be silly, as noted above) ... it would still take 10^27 / (1000000000000 * 60 * 60 * 24 * 365) or on the order of 10^7 or 10,000,000 years to fully exhaust the keyspace.

Your seven-word Diceware passphrase is not even faintly vulnerable to a "dictionary attack". You could literally tell a professional password cracker with a roomful of GPUs exactly which dictionary you used, what the separator is, that they're all lower case, and that there are seven words in the passphrase ... and they wouldn't be able to crack that WPA2 in your lifetime.

And even if I made three major errors in this math (which is likely, since I'm typing fast) ... and even if each of those errors makes my math off by an order of magnitude ... that's still 10,000 years.

Diceware passwords are considered to be strong for a good reason: the math doesn't lie. (And they're great for WPA2 because they're easy to type into all the weird wireless gear you have in your life.)


Is any of my data shared with my budgeting app yet? So I download this budget manager app called Emma, created an account, until it brought me to a login page where I was supposed to enter my back account details.. I didn't expect this, and I wasn't thinking and started to enter my username and password and clicked enter, and turns out the username was incorrect... then I stopped and wondered if I should be doing this.

Doing some research about Plaid, the financial 3rd party handler Emma uses, it doesn't seem to be too safe, so I want to delete this app but I have a few questions.

1) I already signed up using my email and password, I want to delete my account, but that means I need to be able to go into the app, which I can't do if I can't link my bank account. Is it okay if I just leave my account registered?

2) I already sent my password to Emma when I used my wrong username. They know the bank I tried to sign into as well, is this unsafe?

Thanks!

tl/dr: Passwords are like old food: when in doubt, throw them out.  If you're worried just change your password.

3rd Party Financial Services
First some background: the banking industry can, unfortunately, be a bit behind the times in this area.  As a general rule of thumb there isn't yet a great way (at least in the US) for 3rd party financial services (such as Emma) to easily integrate with banks.  I'm sure that some banks have well-secured API services for just these sorts of things, but many banks (especially smaller ones), just don't.
As a result it is unfortunately common for 3rd party financial services to access your account by asking for your actual online banking username and password.  It's a terrible idea, and it really shouldn't be done like that, but unfortunately it is.
One (of the many) reasons why it is so dangerous is because it teaches people to hand over their usernames and passwords.  When you have a service you integrate like this and then use it successfully for a while, it makes it seem less crazy when a scammer comes around and says, "I just need your username and password".  Anytime someone asks for your username and password to your online banking the default response should be exactly what you did - "NO WAY!  You're crazy!".  Unfortunately though, the fact that a service asked for your username/password doesn't actually mean that it is a scam, because in many cases that is the only way that legitimate 3rd party financial services can actually access your data.
Unfortunately telling the difference between "Legitimate and safe 3rd party service", "Legitimate but unsafe 3rd party service", and "Outright scam" can be very difficult or just impossible.  That leaves a lot of people in your boat.
Can you leave your account partially registered?
This is really up to you.  If you signed up with a strong password then you probably have very little to worry about.  Personally though I would reach out to their customer service and ask them to delete my account.  You may or may not have success.
Password in Username
Only Emma would be able to tell you the implications of accidentally sending your password in the email field.  Personally I wouldn't be too concerned.  It is possible that they log all details of all failed login attempts, and therefore there is a plain-text copy of your banking account password somewhere in their system.  From my own personal experience though I don't expect many companies do this, so the risk is likely low.  Either way an employee seeing that in the logs, fetching your bank account info, and trying to login to your bank account to do something malicious is probably also very unlikely.
Still, think of this as a risk/benefit analysis.  The risk of someone seeing your password and trying to log into your bank account is hard to predict but probably low.  However, the cost of changing your online banking password is probably also very low, and the benefit of doing so is that you no longer have to worry about whether or not someone will use your old password.  As a result, if you're worried, just change your online bank account password.


Protect database resources from fake data inputs via web forms Scenario:

I'm working on a project that needs to accept large amounts of data (customer data) from its users. So it can be normal to have a user trying to add 10,000 or 100,000 records at a time. In some other forms its normal to add 2 or 3 records at a time. In some others 50 to 100.

Problem:

How can we prevent our website forms from robots(or humans) that try to add massive data in order to fill my database resources with wrong or useless data.

Possible solutions that I have ruled out:

Limiting the amount of data is currently not an option, as mentioned.
Using CAPTCHA for each form is very manually intensive, as there may be 10000 forms

The question:

So what options do I have to prevent robots/automated tools from accessing the system?

To authenticate users, you use authentication mechanisms.... The answer to your question, as stated, is to provide logins.

If you want to prevent authenticated users from filling your database with erroneous data, then you need correlation mechanisms. Make sure the data entered conforms with what is expected and what can be correlated with existing entries. Just like financial applications need to correlate transactions with other transactions, to ensure that new data cannot be 'invented'. Alternatively, the user data can be validated after it has been entered by a human, or a heuristic algorithm to determine expected ranges of values.

If correlation is not possible, then you cannot trust the data in the database. This is fine when the only people depending on the data are the users entering the data, but if you require other users to depend on the data, then you need accountability mechanisms. Be able to push back on the users to ensure that they conform to requirements.


how does spotify do oauth(+open id connect) from the desktop app? I understand what the workflow would be from the webpage, but how does oauth+open id work for desktop apps as they cannot open a browser page within the app. I see that when I click on log in with facebook in the spotify app, it opens facebook in the browser and returns the control back to the app once the user interaction part is over. But what happens under the hood?

This would be the regular workflow from a webpage based on my understanding from here: https://www.youtube.com/watch?v=996OiexHze0

User clicks authorize with xyz on app
xyz authorization page is opened for authorization grant
User interaction to allow scope of grant, in this the scope is opend ID connect or some thing like that for login
callback page on app is opened with authorization grant from xyz
In the backchannel, app communicates with xyz along with the authorization grant for open id login to get the access token from xyz

But considering a desktop app like spotify which cannot open webpages and receive the response back from the service provider (facebook) with the authorization grant, what would be the workflow under the hood?

They use a concept sometimes called "Universal Links" or "App links". Here's an example of how those are implemented in Windows: https://docs.microsoft.com/en-us/windows/uwp/launch-resume/web-to-app-linking and here's one for iOS apps: https://developer.apple.com/ios/universal-links/

The idea is that these are HTTPS URLs that can be mapped to particular applications in your environment. Assuming they are mapped properly, the app will launch rather than a browser. However, if the app isn't installed / mapped properly, then (since it is still just an HTTPS url) the browser will load the URL instead. The URL they are given contains the auth code necessary to complete the OAuth grant, just as if it were a normal web application.


Exploitation: EIP refuse to jump to the stack although it's executable I wrote a program in C that is exploitable to BOF.

  TL;DR - My payload (NOP-sled + shellcode + return address) overrides EIP but I can't set EIP to point to the
  address of my payload, although I can set EIP to
  be anywhere else outside the Stack adress-range. Stack seems to be
  executable and the proections I familiar with are off.

I sent a payload using ragg2 De bruijin pattern, and found the offset that overrides EIP. I then created a payload with NOP-sled, then shellcode, and at the offset that overrides EIP I wrote the address of the middle of my NOP-sled.

So the payload looked something like this: NOP-sled + Shellcode + Address somewhere at the middle of my NOP-Sled (Little Endian).

Something strange happened and I wasn't able to exploit the program: after the segfault, EIP wasn't at the address I used at the end of my payload, EIP was like 600 addresses after. But when I changed the address at the end of my payload to something else, like "AABB" (0x42424141), or 0xd4d4fdff (instead of 0xd4d4ffff that is an address at the middle of my shellcode, little-endian) it worked just fine and EIP was at the address I supplied.

nx protection is off, ASLR is disabled, Selinux disabled, the memory page seems to be executable and the ELF compiled using "-fno-stack-protector -z execstack" on GCC.

Tried it also on gdb and also outside of any debugger.

what can be the problem? Why it refuses to jump to the address on the stack?

Info about the binary:

havecode true
pic      false
canary   false
nx       false
crypto   false
va       true
intrp    /lib/ld-linux.so.2
bintype  elf
class    ELF32
lang     c
arch     x86
bits     32
machine  Intel 80386
os       linux
minopsz  1
maxopsz  16
pcalign  0
subsys   linux
endian   little
stripped false
static   false
linenum  true
lsyms    true
relocs   true
rpath    NONE
binsz    6162

Info about the stack:

sys 132K 0xfffdd000 - 0xffffe000 s -rwx [stack] [stack] ; map._stack_._rwx

EDIT:
You can find more details, including commands and the shellcode itself here:
http://pastebin.com/HYbByNSE

Based on the payload that you posted, It seems that you want EIP to jump to 0xffffd4d4. Set a breakpoint at that address (0xffffd4d4) before running the program. This way you will know if program execution ever reached 0xffffd4d4.

Maybe there is a problem in the Shellcode and your program might be segfaulting halfway through the shellcode. I had a lot of similar problems when I had started out.

PS. In your question you mentioned 0xd4d4ffff. Please check. Because if you want to jump to 0xd4d4ffff you need to replace EIP with \xff\xff\xd4\xd4 and not \xd4\xd4\xff\xff.


Which OpenSSL commands update the CA database index file? Have I understood correctly that when CSR is signed with openssl x509 tool, a CA database index file is not updating ? As opposite, when signing with openssl ca tool, then index file is updating.

This is correct. openssl x509 is only a tool to manipulate and create certificates, but it is not a standalone CA and does not keep any status. Whereas openssl ca is described in the documentation as:

  The ca command is a minimal CA application. It can be used to sign certificate requests in a variety of forms and generate CRLs it also maintains a text database of issued certificates and their status.

This text database includes the index file you refer too.


Is it safe to protect the write permission only with a publicly accessible hashed password? A user stores a raw information (a comment on a website, a like on a post etc.) in a database. He pairs it with a hashed password and keep the original password safely for him/herself. This password is required to modify or delete this data.

Let's say the password is randomly generated, long enough, the hash algorithm is very strong (I know nothing about cryptography).

Can this model be considered safe enough to let anymore read the entire database?

Such a database would contains only public informations, nothing secret. The password behavior is here just to protect the write permission on any data.

Blockchain database like Bitcoin works on essentially the same constraint and principle. So yes, it can be made safe. With that said, it's easy to get this wrong and unless you're doing something like a Bitcoin, there are often simpler and easier ways to achieve the same security goals. There are also lots of ways to make something that matches your description that is insecure, so your description itself isn't sufficient to rule out that it may be insecure.

The main technique to secure such database though, is that you need to use asymmetric cryptography. Rather than using passwords, you instead cryptographically sign any data you authored with your private key that other people can verify using your public key. A public key can be published publicly and can be read by anyone without compromising the security of the system, the private key is the "password" that one can use to prove that contents you author and an amendment to those contents is made by the same author.

If you don't want users to deal with managing a key pair and if you trust that your users don't use weak passwords, it's certainly possible to publish an encrypted version of your private key to the database and use a password to encrypt that password. If you do this, then from users' perspective everything will look and behave exactly the same as what you described, in that your authorship is protected simply by a password, though the difficulty of enforcing everyone to use strong password means that this is likely to be weaker in practice than if users just keep their private key to themselves instead of publishing the encrypted private key.


How to check an Android Application for SQL Injection or XSS bugs? I was just wondering how could i check my client's Android application for SQL Injection or other similar kind of bugs.

I mean if its an application, where should i write the queries. If through ADB, then how?

SQL injection requires that some part of the application can take input and be persuaded to pass it to a database as SQL commands, so testing all input fields with your SQL test strings is key.

John S's question on how to test for SQL injection on input fields is relevant whether those fields are in an application or on a website.


Can your ISP tell what google account searched what? And can they share this information? If you search something, can your isp share the google account it was searched from?

Google uses HTTPS, which means traffic to / from Google is encrypted on transit.

Thanks to that encryption, your ISP can't read anything in the traffic: neither the search terms nor the Google account.


Fuzzing authenticated part of web application I have a web application I am wanting to fuzz. It consists of a lot of REST webservice gets/puts. I have been considering using Sulley Fuzzing Framework or its successor boofuzz.

Since the jsessionid and/or other authentication cookies change for each time the user logs into the application what is the best way to handle logging into the application and then to grab the necessary cookies.

Can I then add them as s_static parts of my sully/boo session?

Any tips / pointers to documentation would be helpful.
Also if there is a better tool to use I would consider it as well.

Thanks

As you asked for other tools, here's a vote for the (amazing) Python Requests library. It makes writing your own tools way easier than it used to be. Writing automated logins is dead easy.


How does a flash pathogen manage to act as a key logger? It has been mentioned in security forums that the latest malware pathogens permit malefactors to record your keystrokes and send them to a server. As a result I've put a command in my ~/.profile to delete the ~/.Macromedia directory everytime start up a new Terminal window. However I am curious as to how flash does this, and whether closing a browser window/tab really causes such a key logger to exit.

Thanks for any clues.

As Iszi noted, a lot of the threats from Adobe products come in the form of privilege escalation and remote code execution vulnerabilities in Flash, rather than features of Flash in general that can be used maliciously. If a malicious Flash script (or PDF, or executable, or anything else) can successfully compromise a machine, any variety of key loggers or network sniffers may be installed.

Additionally, there have been several Flash file overlay vulnerabilities. These problems allow a maliciously designed Flash file to detect keyboard input and mouse clicks without the user's knowledge. The primary purpose of these scripts is for clickjacking, however they could easily work as some sort of a key logger as well. It's important to note that these flaws are browser-based, not backgrounded Flash files.

In terms of defense, certainly removing a ~/.Macromedia directory couldn't hurt, but it might make sense to also killall npviewer.bin, which will kill all instances of Flash running on your Linux system.

Hope this helped!


If there is a malicious attack on one partition, is the other one safe? I recently have used Bootcamp to set up a new partition and run Windows 7. About half of my HDD is designated to my OS X partition and the other half is allocated to the new Windows 7 partition. If something were to happen to my Windows 7 partition with Bootcamp, is the OS X partition still safe? Or is it at risk due to Bootcamp being a link between the two?

If both partitions are at risk, what steps can I take to minimize the damage that could be done in the event that an attack occurs?

Boot Camp allows you to make two operating systems coexist on the same hard drive (but in distinct areas, called "partitions"), and to choose which one is started when you power up the machine. However, each OS, once started, sees and can access the whole machine. In particular, Windows, once started, is aware of the existence of both partitions, and can read and write both as it sees fit.

Both Mac OS X and Windows are "well-behaved" in that they know which partition is theirs, and which is not; and they refrain from altering the other partition contents in any way. However, malware is usually not well-behaved (by definition), and malware that runs on Windows may notice the existence of the OS X partition and begin to alter it for its nefarious purposes. It is thus at least conceptually possible that a virus running on Windows infects an OS X partition. This is not Boot Camp itself that puts both partitions at risk; it is the very concept of multiboot.

In practice this is not very likely to happen, because the Boot Camp situation is sufficiently rare to make the development of a cross-OS virus not worth the effort. Possibly, a destructive virus that bombards the whole disk with random bytes may impact the OS X partition as a collateral damage.

If you want some higher degree of isolation, use a virtual machine. In a VM, the guest OS (e.g. Windows) does not see the real hardware, but an emulation of a virtual drive that the VM solution synthesizes for the guest. Normally, the partition of the host OS (e.g. OS X) will not be made visible as a virtual drive to the guest, so even if the guest is hijacked by hostile code, its potential damage won't extend to the host partition.

This, of course, assumes that the VM solution does not have an exploitable hole that would allow an hostile guest to evade from it and run its code on the host. Also, some practical VM setups often actually make the host partition, or a subset thereof (e.g. a given directory), visible to the guest, to ease data transfers between host and guest.


How to encourage responsible disclosure (and react appropriately otherwise) As a conscientious programmer, I put security as one of the core requirements of every product I develop. To prevent flaws from being introduced, I promote a culture of awareness (e.g. make sure that team members I work with know about common vulnerability types), keep myself updated by regularly reading specialized sites (e.g. The H Security or Dan Kaminsky's blog), watch out for common mistakes (and discuss them if necessary) while performing code reviews.

However, we all know that, by Murphy's Law, a security bug will appear (sooner or later). My (closely related questions) are:

How can I promote responsible disclosure of security vulnerabilities found by researchers? That is, how can I encourage them to collaborate jointly with me, not releasing details until a fix is prepared, while simultaneously ensuring they feel they are respected for their hard work and they get the credit they deserve?
In case someone takes the full disclosure route, how can I react (be alerted of the vulnerability as soon as possible and then take appropriate mitigation measures) in the most timely and effective way?

At the moment, I've thought about:

making sure a security contact is clearly listed on my website
using CVE Details to get a feed for my products if they get published there
following security mailing lists as well (see this IT Security answer)
ensuring patches are prepared quickly
constantly communicating with the bug reporter(s), updating them as progress is being made
publicly crediting the researcher(s) for her/their discovery
allowing full disclosure some time after the patches are published (to allow affected clients to install them)

(I'm part of a small team in a sort of startup, therefore my course of action is not limited by managerial issues. Nevertheless, I still think that any advice you'll provide can be applied to other situations as well.)

How can I promote responsible disclosure of security vulnerabilities found by researchers? That is, how can I encourage them to collaborate jointly with me, not releasing details until a fix is prepared, while simultaneously ensuring they feel they are respected for their hard work and they get the credit they deserve?

I think you are on the right track so far with this point. The most important thing is to have an easy way for security researchers to contact you about security flaws. Keeping them involved in the process of fixing the bug is just being polite. If the bug is serious enough and you are able to afford it (which might not apply to you since you are a startup, offer the researchers a bug bounty for their efforts).

The worst thing you can do is be rude to the researchers and ignore their efforts to work with you on fixing the bugs. See this very hilarious case.

  In case someone takes the full disclosure route, how can I react (be alerted of the vulnerability as soon as possible and then take appropriate mitigation measures) in the most timely and effective way?

You are also on the right track for this. I don't think there is a more effective method of discovering full disclosures about your software's vulnerabilities besides monitoring the various vulnerability databases available. You might want to look into subscribing to the feeds that such databases push out and use a regex filter to sort through irrelevant information.

If someone does something like this, I'd say the most important thing you should do is keep your customers informed. You might feel that this would negatively impact your reputation, but trust me, it would be a lot worse if your customers get hacked as a result of your software.

Keep them updated on the progress of the fix. If a timely fix is not possible, suggest alternative methods of mitigating the damage.


How to determine if JPG EXIF data has been changed by "OEM" software (without third party tools)? I have a JPG and I am analyzing it to determine it's efficacy. The image metadata clearly indicates that the image was digitized at 15:10:13, Dec 31, 2015 and I need to determine if this date digitized has been altered in any way.

Notes:

I have forensically the image in question (maintaining chain of custody) from the receiver's iphone6.
The sender used an iphone4s.
No other received images from this (or any) sender have been found to have a mismatch of EXIF data.
From this answer, I can see that it would be difficult to prove with absolute certainty that the data has or has not changed but I am more interested in the how the data could have changed (in reasonable ways -ie no alien hackers).
Just to clarify, there is no reasonable suspension that the sender deliberately directly altered, had someone else alter, or has been affected by malware that alters the EXIF data.
The GPS TimeStamp says 20:10:23 UTC Dec 31, 2015 which does correspond to correct localised timeStamp.

Assuming the sender:

Does not have any third party apps installed that can modify EXIF data.
Has no intent/motive to edit EXIF data.
Is not infected with malware that does edit EXIF data.
Both the receiver and sender used the iMessage app and the message was sent as an iMessage.
Both the receiver and sender are on the same cell carrier (T-Mobile) and located in the USA.
The timezone of the sender and receiver are the same and no timezone travel has occurred in the sample period.
The date and time on the sender and receiver's devices are correct.

I cannot replicated the alleged modification. Here is what I have tried:

As per this article, I have tried sending a control JPG within the iMessage app via take a photo. This had the effect of limiting the EXIF data (did not have sensor data or DateTime Digitized) and eliminated GPS data altogether which is the opposite of the alleged modification.
Sending various control JPGs that include the follow control cases; have not been modified at all, been edited in Apple's own image editor (eg just cropped), taken with front and rear camera, sent via the select photo option in iMessage as well as sent directly from Photos app.
Sent image in various states (as described above) with and without a message added to the imessage (ie when adding the photo by any means I added "test" text to the message before sending the imessage.

From what I have tried, I conclude that the date digitized is indeed valid however there is reason to believe it is not and we need to determine how it could have changed (within my parameters -ie no third party app or person).

How could the EXIF data have be changed automatically, specifically the "DateTime Digitized/Original" data? Is it likely that it can be changed via iMessage, Apple, the IOS, or the Iphone(s) at all?

I have included a snapshot of the EXIF data (from Apple's more visually pleasing inspector tool, the actual forensic examination shows the same thing in binary.

This could be due to many reasons. I'll share the most likely:

The user has an app to randomize/change EXIF data/file property data. There's an app for that. Such a program is usually used by those who are paranoid and want some kind of plausible deniability, or maybe they're just bored and messing with you.
iMessage should allow you to send images with EXIF data intact, while standard MMS will not. This is a limitation of the MMS protocol. iMessage and MMS aren't the same. Note that you can remove GPS data by not allowing geotagging in the settings. Try another control picture with geotagging enabled in your iPhone. Settings > General > Location Services > On/Off.

  This is an idea but there shouldn't be any EXIF data on here if the picture 'started out' as an SMS picture...

Notice that this is from the iPhone 4. The iPhone 6S is the current phone. Things have changed. Your link is from nearly 4 years ago. Updates can add or remove features, even on older devices such as the iPhone 4s, your target machine.

Since we are talking about forensics, you might be working in law enforcement. If this is the case, then you should try to get a hold of an updated iPhone 4s. Take a picture of anything, and use iMessage to send it to another one of your devices. Verify that the EXIF data is either intact or missing. From there, you should be pointed in the right direction.

If you have already seized the iPhone in question, and you found the EXIF data on the iPhone, it's possible it didn't get transmitted via SMS. If you got the EXIF data from a phone that received the SMS, then you'll know it can be transmitted.

The article I linked seems to suggest that EXIF data is now included by default. Many other articles indexed by Google also suggest the same.


What do the security warnings from cflint mean? I am going to use the open source tool cflint but I would like to know what some of the warnings it lists actually mean or what they imply.  The warnings in question are ones relating to security:

  QUERYPARAM_REQ -  SetSql()  statement should use  .addParam()

and

  CFQUERYPARAM_REQ -  cfquery  should use  < cfqueryparam>

Given these warnings, what problem do these indicate with the security of a program?  I understand what fix they are suggesting, but what problem does this cause for security?

It sounds like it's asking you to use parameterized SQL queries to prevent SQL injection. Using parameterized SQL prevents first order SQL injection attacks by treating the input as a parameter, rather than just concatenating strings.  For example, consider the following query :

  "Select * from dbo.Users where Lastname='{value}';"

Assume a malicious user is attempting to input "' or 1=1; --".  Using regular concatenation, this query becomes

  Select * from dbo.Users where Lastname='' or 1=1; --;

and the application will return all rows from the users table.  With parameterized SQL, the query will become

  Select * from dbo.Users where Lastname=''' or 1=1; --';

and will only return rows where the last name matches "' or 1=1; --".

This stack overflow post may also have some useful information.


How do I deal with companies that call and ask for personal information? Several times I get a phone call from a company- my bank, utility companies etc. Many times they are just cold calling me, but once or twice they were calling for legitimate reasons (ie, something to do with my account).

The problem is, all these companies ask you to confirm your personal details, like date of birth. Now I have no way of knowing if the person calling me is the real company, or some phisher (because even if the call isn't from a blocked number, it's just a number and I have no way of knowing who owns it).

Usually, when they ask me to ask for personal details to prove my identity, I tell them since they called, they should prove their identity.

At this point they usually get irate and warn me they cannot go ahead for security reasons. Now I don't want to miss out on important calls, but neither do I want to give out my personal info to anyone who manages to find my phone number.

Is there a proper way to deal with such calls?

I react exactly the same as you- I first ask them to authenticate themselves to me, after all,  they called me. If they can't or won't I tell them that I will call my bank manager/utility rep/whatever and that if this is an official message I should be able to receive it after authenticating the usual way.

Don't give in to them- they need motivation to start doing this right.


TOTP / HOTP - Offline 1 hour password generator I need to generate and valid a password / token for an hour.

Client -> generate password (valid for one hour)
Server -> valid it within an hour.
//System needs to work offline (TOTP)

TOTP is normaly 30 seconds... So if i change the TOTP interval to 3600 seconds will i then break the security?

Also open for any better ides then TOTP ?

That is not a good idea for several reasons:

OTP has to be second factor! It can not be the only factor in authentication
30 seconds for TOTP is secure because during that time attacker can not test all the possible options + the first factor.

For 6 digits it is 1000000 combinations and after 30 seconds (>3000 combinations per second), the combination is different.
If you extend this time of validity to 1 hour, attacker have plenty of time to brute force this combination (~27 combinations per second)

For this use case, you should choose different way of distributing password

SMS
Password is enabled for that one hour by something on the server side( in that case you need to protect that password).


Is it normal for a website to show an API key in plain text that allows full access to your personal information? I noticed some websites do this and I am not sure if this is normal or not. So for example, on some websites, I go into setting and can create an API key that will be visible in plain text. Also, seems like a lot of HTTP requests have an API key visible in the URL. Something like this "https://www.myWebsite/user?apiKey=\(apiKey)". Any insight on this is appreciated.

"Normal" may be the wrong choice of words for your question. The real question is... "Is it secure?"

Breaking the question into different parts, here's my take at an answer:

1. Is it secure for a site to provide me with an API key?

Providing you with your own API key isn't a problem, since it's your key. This is true as long as the page is served using https. Serving the page unencrypted would allow anyone between you and the web server to also see your API key.

2. Can an API key be passed via URL and still be kept secret?

No. Passing an API key via the URL means that key is stored in the server's logs, in a browser's history, visible to browser extensions, accidentally copied / pasted by a user, etc. It is no longer a secret. This is true even if the page is served via https.

3. Does an API key need to be kept secret?

This question may be a good one to explore. Maybe the service you're referring to provides an API key and a Secret key. The API key can be exposed via URL but the Secret key must be used to calculate a certain header that must also accompany the request.

Another example might be an API that's expected to be called via JavaScript. In this case, anything in code will be exposed to the client. Again, the service provider may expect a key that is derived from your secret key to be passed via the service.

Alternatively, maybe none of the keys are secret but the service employs IP address whitelisting to ensure that the keys can only be used by your server. They could also do hostname checking and allow you to specify valid hostnames in your account that the key is allowed to be used for.

Summary

Ultimately, the technique that a service chooses to use to protect its keys and secret keys should match the need to keep them secret, or the need to protect unauthorized users from calling the service. In some cases it doesn't matter if someone uses your keys to call the service.


Defence for brute force attacks to ssh At some point in the past I had a small (physical) webserver. From day 1 there were brute force attacks to ssh.

I looked it up a bit and I set up iptables to block IPs that try to connect to ssh more than twice in a 2 minute period. This lead to distributed brute force attacks from whore ranges of IP addresses.

Eventually I solved my problem by allowing only an other computer that I had an account on to connect to my ssh. However the question remains. If login only with keys is for whatever reason inconvenient, how can one defend against brute force attacks to ssh?

The best defenses I have found for the host machine are these:

Disable Admin login
Disable password login for users, RSA keys only, if you need more security look at ECDSA.
Disable ICMP if you can (Considering you're a web server...)
UFW and IPTable rules doing what you specified and make sure
IPtables is logging the incidents.
Fail2ban - Install, configure, etc.
Denyhosts - Install, configure, etc.
Install logwatch with verbose output to maintain a clean view
of your logs at a moments notice.

Network/router rules can allow white-listing which, if deployed properly, is very very effective.


Why are security properties non-compositional? I had a lecture in security and it was stated that security properties are non-compositional. I don't quite understand what that means and can't find anything in the internet about that.

Can anyone explain?

Secure+secure != secure

What "non-compositional" means by definition is that if you have two components/thingies/processes/whatever that each on their own are secure (i.e. satisfy some security property) then, in general, you can not assume that the combination of these two will satisfy that security property; having both these together can make them both insecure.

This general principle applies to many domains of security from app development to theoretical cryptography; many practical exploitable vulnerabilities occur from an unexpected interaction of two parts that each, when viewed in isolation, would be perfectly secure.


Security on dedicated lines Is it safe for a company not to use any encryption on customer's data when it is transferred between data centers on dedicated lines?

By customer data I don't mean passowrds/credit card info. Just simply hosted customer data (files).

It is safe not to encrypt sensitive data in transit over some wires only insofar as no evildoer may physically access these wires at any point. So, in fact, no, it is not safe. In urban environments, cables run most of the time through tunnels shared with a lot of other usages (e.g. sewers or subway tunnels) and not under robust shielding or 24/7 guardianship. In the countryside, such links will often be buried in trenches not far from roads, and can be preyed upon by any attacker with some dedication and a shovel.

A 75 years old grandmother once shut down the quasi-totality of Internet access in Armenia in similar circumstances. Assuming that things are more "protected" in richer countries (like, say, Western Europe or the USA) would be a gross miscalculation of what cost/benefit analysis means. Cables are left unprotected because nobody would accept the price of physically protected cables, both in Armenia and in New Jersey.

Of course, that's only customer data. Nothing important, then.


What is the problem with multiple encryption and how do you know if you have decrypted a cipher? I have 2 questions that are somewhat related:

When you try and guess the key in a program (in a brute force way), how does the program know if it got it right and it had deciphered the message (I'm not talking about the obvious files with headers, but just a long string of text)?
What is the problem with cascade encryption/multiple encryption? If the only way to answer question 1 is to use something like a language processor, then aren't all multiple encryptions unbreakable using brute force methods?

For multiple encryption, there was a previous question:  Is multiple encryption a good idea?

As to how do you know if you decrypt it correctly -- usually you look at the output and decide if it makes sense.  E.g., does it have the file format of a gif/jpeg/zip file?  If it was plaintext does is it all ASCII or properly encoded UTF-8?  Ignoring non-ASCII code-points, only 96 of the 256 possible values of a byte are printable.  So if you decrypted garbage message with the wrong key and the message was 1000 characters long, the chance that all of them are printable ASCII letters by random chance will only be (96/256)1000 or about 1 in 10400.  Even allowing UTF-8 the characters have to be in certain combinations; e.g., if the first byte is of the form 1110xxxx (where each x could be either a 1 or 0), that means the next two characters both need to be the form 10xxxxxx to be proper unicode).  These sorts of things rarely happen by chance.

There's also often padding (that needs a certain form in the plaintext), checksums, or Message Authentication Codes that help distinguish garbage data from the wrong key, from actual data.

EDIT: If you encrypted a file twice with two different (symmetric) keys k1 and k2 and you tried decrypting c=E(k1, E'(k2, m)), there isn't a way you could just brute-force guess k1 by just examining the output of D(k1', c), which will appear random for any pattern.  You would have to brute force, k1 and k2 simultaneously to figure out properties of m.

However, its extremely infeasible to guess a high-entropy private-key by brute force.  The amount of work to brute-force a 128-bit AES key is about 2128, e.g., a billion (109) computers testing a trillion (1012) keys per second for a 1000 years would only have a 1 in 10 million chance in finding the right key.  So the gain from multiple encryption in this scenario doesn't seem to be much.

On the other hand, if you had asymmetric encryption with a known public-key, you can quickly check if the guessed private key is correct -- can you encrypt a message with the known public-key and then decrypt it with your guessed private key to recover the original message?


lost key-files for encrypted files I had encrypted a file on my computer but the computer got infected by a virus, so I reinstalled Windows on my computer. All my key-files have gone.

Is there a way to recreate the lost key-files, as I know what the password was? Can I decrypt my encrypted files once again?

You should describe problems in detail. For example, what algorithm was used to encrypt the file.

If you encrypted the file with a key-file using a strong encryption algorithm you won't be able to decrypt the file without this key-file. The password for the key-file won't help you if you don't have the file. This is a kind of two-factor authentication.

You can not regenerate the key-files. They are generated with random numbers. It is good that you cant regenerate them. If you would be able to do this an attacker could be able to.

The only way you can get back your files is trying to restore the key-files. If you are lucky you are able to restore them from your hard drive.

Your lesson learned should be to back up your keys.


How to make dnsspoof work for https sites? I tried to dnsspoof the victim machine for say "www.imdb.com" (with the help of setoolkit and ettercap). But the site is ssl https, so I read here that dnsspoof won't work for https sites. As quoted in the link provided :

  As part of the SSL handshake process, your server will need to send a valid certificate for securesite.com which contains the public key.

  At this point, you have 2 options.

  1) Send the legitimate certificate. This will check out since the certificate is signed by a trusted CA. The client will then encrypt the master secret using the public key. It breaks down at this point, because without the private key, you cannot decrypt the master secret and thus you can't finish the connection setup.

Is there a way to "send the legitimate certificate" ?

Is there a way to "send the legitimate certificate" ?

If you are the owner of the site you want to spoof then you can get a legitimate certificate from a CA trusted by the browser.

If you are not the legitimate owner you will hopefully not be able to get such a certificate. If you want to create something for internal tests only then you can create your own CA and use this CA to issue your own certificates. Of course you have to add this CA as trusted in each client you want to spoof in order to be treated as a legitimate certificate.

For more see Does https prevent man in the middle attacks by proxy server?


Is it easy to evade a ban if you have a Dynamic IP? Static IP, I get it. Once it gets banned, you are done on that IP.

But what about Dynamic ones? Let's say I am playing on a game server and the administrators decide to ban me for cheating. They ban the IP I was using that specific time, correct?

But Dynamic IPs change pretty often so does that mean I will be able to normally log-in again once it changes? Is it that simple as it sounds?

Does someone have to restart the router in order for their IP to change or can it happen randomly while browsing on the Internet etc? (assuming it's a Dynamic IP)
When an IP changes, does the ISP change it completely or only the last few digits? For example from 94.544.453.erty (didn't want to finish it with numbers) to 94.544.453.sfrf. Or is it possible to also go from 94.544* to like 94.434*?
Do internet cafes have Dynamic or Static IPs usually? The reason I am asking is; if a cafe user gets banned from a server for cheating then does that mean whole cafe (30+ players) is pretty much unable to play on that server?
Is it true that you can't find someone's location accurately if they having a Dynamic IP? For example, it might say that you live 10kms away from your actual location.
If it's so easy to evade a ban by using a VPN or even by having a Dynamic IP then why do they keep issuing IP bans? Is this the only way to prevent someone from having access to something?

Yes, in general a "block" will beaten with a new IP if it's an IP block. I'd suggest VPN as you can't control your ISP and their are different ways that they do IP reservations and NAT. It is possible to block on useragent and some other things also, but in general I see IP bans used the most. IP bans are a flawed way to stop an attacker. When we ban IP's we run the risk of shutting down connectivity for multiple users who share that IP. Why is this still used? There isn't much else when you have a really malicious attacker. Good SOC's and IR are aware of these issues and usually bans have a shelf life: 30 days being one I'm familiar with personally.

Turning your router off and on might, but probably won't change your IP. You will most likely have a "lease" and that will change depending upon it's time limit. Internet cafe's will have IP's based on their ISP and plan, most of which seem to be a standard enterprise plan without anything fancy like a reserved IP range or etc. On the note of if the new IP will be close to the last one, yes most likely. IP's cost money to "own" so typically buy a sequential range so you'll get assigned randomly to another in the range, very close to the last one.

I'd suggest asking the geolocation question separately from this post as it is a very different topic.


Will wireless isolation/AP isolation protect from KRACK? Will using AP isolation on an Access Point protect connected clients from the KRACK vulnerability on that network?

Nope.

Wireless/client/AP isolation only provides a means of isolating one wireless client from another. It has no bearing on how 802.11 encryption works or how the WPA2 handshake takes place.

Since KRACK attacks the WPA2 handshake and compromises the encryption between a client device and the access point, it really doesn't care if the wireless client can reach another wireless client.


What are the security implications of using TOTP for single factor authentication? (Note: I am not actually planning to do this. This question is strictly theoretical.)

TOTP is commonly used as the second factor in Two Factor Authentication. It is an open standard with available implementations in multiple programming languages and platforms. There is an easy to use client app for both iOS and Android in the form of the Google Authenticator app.

Is there any fundamental security issues with using TOTP as a single factor authentication method in place of passwords? Ignoring of course that single factor authentication really should be discouraged.

I have done some thinking on this topic and I would like to present my ideas. Feel free to draw your own conclusions.

Facts

The secret used for the TOTP algorithm is a 80-bit randomly generated key encoded with base32. This probably more secure than the passwords most people use.
The secret key is usually presented in the form of a QR-code to be scanned by the Authenticator app. Alternatively, some services also provide the base32 encoded secret key for manual input.
In an Android device, the secret is stored unencrypted in an SQLi database file. The SQLi file is located at /data/data/com.google.android.apps.authenticator2/databases/databases. However, this file isn't accessible to any application other than the Authenticator app itself. Obviously this does not apply to a rooted device. I do not have a rooted iOS device so I am unable to comment on the specifics of the iOS version of the Google Authenticator app.

My conclusions

In my opinion, there are some benefits and drawbacks to replacing passwords with a TOTP authentication solution.

Benefits

Assuming that the Android device in question is not rooted, no other application besides the Authenticator app can access the secret stored in the database. This removes a very large risk of malware hijacking the secret used for authentication. Any keyloggers/screenloggers will only be able to grab the temporary password that expires in 60 seconds. This is a very small window unless you are the focus of a very targeted attack.
Using TOTP removes the possibility of an attacker performing an online brute-force attack against the service. The window of opportunity is simply too short.
To some people, this is a good tradeoff between security and convenience. Most people I know carry a smartphone around 24/7. Authentication is a simple matter of accessing the app and keying in 6 digits. To some people, this might be easier than having to remember relatively strong passwords or carrying around a password database.

Drawbacks

A database compromise means having to reset the secret. This can be really troublesome for the users.
A user losing his/her smartphone means losing access to the service.

This is quite interesting to think about. However, in the real world you should obviously use regular passwords and one-time passwords together for 2FA.


Can I be tracked down using Tor after not using it again? I used Tor just some minutes ago to send highly sensitive data to the press. This could get me in serious trouble in my home country.

I send that data over a platform that normally connects people to sell private stuff. For that, to use the chat, I had to activate Javascript temporally (within Tor browser).

I used my regular internet connection to connect to the Tor network.

What I can say for sure:

no one knew what I am doing at that moment so there is no current spy etc. on me
All accounts needed for that process (selling portal and mail provider) were created using Tor as well
javascript was activated for that

Should I worry?

This will come out for sure and investigations will come.

Tor is probably one of your best options at being anonymous on the internet.  That being said there are always a possibility of being tracked.  For instance if you had your internet connection tapped before you started using tor and your exit node was one controlled by the same people (big if), they could potentially find out who you were by a throttling your connection in some sort of regular pattern and comparing it with the exit node you used.  In addition there is a small possibility of someone holding a zero day that would allow you to be deanonymized.  Or the version of Tor you downloaded could have been modified by a third party (assuming you didn't check the hash).  You would probably have to be a pretty wanted man for anyone to use any of these techniques though.

Again, Tor is one of your best bets, maybe in the future if you are more worried about it you could also use a anonymizing vpn (who have a canary that is not triggered) and a couple of other proxies.

Edit: not using it again is not really gonna help you.


Crack Linux password if you have plaintext and hash? I have a relatively old Linux system, where password are not shadowed, therefore stored in /etc/passwd/.

My question is, since I know the cleartext password, and its hash (looking at the passwd file), Can I quickly figure out the hashing system/crack it? So I would be able to get the cleartext password from another user just from its hash, or at least make bruteforcing faster?

Thanks.

EDIT: The hash is 13 characters long

The hashing algorithm used is not part of the secret. The hashing algorithm should always be assumed to be known. You can read up to this here.

In fact, the string you find in /etc/passwd or /etc/shadow tells you which hash has been used right in the first number:

$1 → md5
$2 → blowfish
$2 → eksblowfish
$5 → sha256
$6 → sha512


Safety of TrueCrypt hidden volumes According to the documentation a hidden volume stays hidden because it appears as free space. In TrueCrypt free space always has random data in it, however in the case of a hidden volume it's not actually random data but the hidden volume. I was wondering how is it possible to write (for example add a new file) to the outer volume with out risking overwriting the hidden volume?

As of TrueCrypt 4.0, it is possible to write data to an outer volume
without risking that a hidden volume within it will get damaged
(overwritten).
When mounting an outer volume, the user can enter two passwords: One
for the outer volume, and the other for a hidden volume within it,
which he wants to protect. In this mode, TrueCrypt does not actually
mount the hidden volume. It only decrypts its header and retrieves
information about the size of the hidden volume (from the decrypted
header). Then, the outer volume is mounted and any attempt to save
data to the area of the hidden volume will be rejected (until the
outer volume is dismounted).

Wouldn't this make it easy for an attacker to learn there is a hidden volume? As soon as he can't write to free space he'd know.
For example if an outer volume is created of 5 GB and an inner volume is created with 4 GB. An advisory forces the owner to reveal the password but is given the decoy password to the outer volume. Then the attacker wouldn't be able to write more than 1 GB (at the most) before seeing that there's a hidden volume.
Do I understand this correct? Is this a concern or is there a safeguard against this? Does it help to make the outer volume large so the chances of writing to the free space with the inner volume are low. If one was going to store a virtual machine in a hidden volume, that would take up quite a bit of space. It would be quite consuming to double this size by giving lots of room to the outer volume.
Also, what kind of "fake" sensitive files should go in the outer volume? If you think about it, it's not that easy to make fake confidential looking documents. You wouldn't be able to store any online passwords because they could be verifies as false easily.

For example if an outer volume is created of 5 GB and an inner volume
  is created with 4 GB. An advisory forces the owner to reveal the
  password but is given the decoy password to the outer volume. Then the
  attacker wouldn't be able to write more than 1 GB (at the most) before
  seeing that there's a hidden volume.

It would not work like that. If forced, the owner would reveal only the outer volume password, and deny there is any other.

Then the attacker would be able to write to the whole 5GB, thrashing the secret data but unaware of its existence.

The owner, instead, while maintaining the outer volume, would give both password and so be safe against inadvertent overwrite of his "true" data.

  Also, what kind of "fake" sensitive files should go in the outer
  volume? If you think about it, it's not that easy to make fake
  confidential looking documents. You wouldn't be able to store any
  online passwords because they could be verifies as false easily.

You would just put in there something which you plausibly wouldn't want revealed, not necessarily confidential. Depending on the situation, some embarrassing flavour of porn might do. It would also help explain why the files aren't all that up to date; the "secret volume" is mainly there to be read (well, viewed), and gets only occasionally enlarged with new porn.


Data Security on a Malicious WiFi Network Let's assume that I unwittingly connect to a malicious WiFi network and visit some websites. By malicious, I mean the network has been set up for the purpose of stealing data.

From what I've read, using https:// is safe. Is this true for networks set up for malicious purposes?
If I visit websites where I'm already logged in, and thus don't enter any passwords, can my credentials to these websites be compromised? What about session hijacking?

From what I've read, using https:// is safe. Is this true for networks set up for malicious purposes?

If done right https is still safe. But, if you (actively) accept any kind of untrusted certificate (self-signed or signed by unknown CA) an active man-in-the-middle attack is possible. If the attacker owns a public root-CA or some intermediate CA or managed to issue specific certificates it is even possible to mount such attack without needing the victim to actively accept the spoofed certificates. While this is unlikely it was actually done.

If you are connecting to a site which uses public key pinning or certificate pinning (like access to google.com from Google Chrome) you are still safe in this case, but only for accessing these specific sites.
If the attacker instead managed to steal some high value certificate or issue such certificate for sites not protected by pinning, than it is possible to do harm on other sites too, because high-value sites like google-analytics.com, jquery.com etc are often included as script into other sites.

  If I visit websites where I'm already logged in, and thus don't enter any passwords, can my credentials to these websites be compromised? What about session hijacking?

For HTTPS you should be safe (see above). For plain HTTP it depends a lot on the site. Some sites not only use a random session cookie but also add browser fingerprint into it. This makes session hijacking harder but usually not impossible. Other sites instead let you change the users password or the reset e-mail without asking for the old password. In these cases a permanent takeover of the account is possible.

EDIT to summarize the good comments here: any security collapses when you use unencrypted HTTP (or FTP). From then on sslstrip, script or HTML injection etc make it possible for an attacker to hijack anything. So you better disable HTTP and FTP , which could be done by setting the relevant protocol proxy to something non-existent.


Someone is injecting malware into my website My website was hacked last year and someone had uploaded a script which was hogging up all CPU and load avg went up to 30+ till our hosting provider temporally suspended the account, that was a few days after installing WordPress (I didn't know PHP is so vulnerable to hacking). I had to disable many options in php.ini and after that there was no problem with my site for over 300 days.

But since the last few weeks someone is again trying to defame the site. He is constantly uploading malware to my site. But the worst part is the malware is not always there, it is only detected by Google Webmaster that too once in few days. I removed WordPress, now it's all static HTML (as I feel PHP is not that secure) and still the hacker is able to inject malware once in a few days for few hours only.

A page gets blocked by Google Webmaster and no other pages are touched. I changed all my HTML and CGI files to a different permission. Apache cannot write on any of the folders now, removed all PHP scripts last week and I thought that should safeguard my website from future attacks.

But this morning, when I visited Google Webmaster, I was surprised to see a warning of my website having malware! And that too in an "apk" file this time.

Question:

So my question is, how on earth someone is able to upload a malware which gets downloaded automatically when an APK is accessed! Even when there is no permission for him to write to that directory!

I have been programming for the last 10 years and this is beyond me. Nothing in the Apache logs, nothing in any folder. The file modification search also shows nothing is touched since the last 10 days and yet the hacker manages to allow a malware to be downloaded along with my apk and that too only for few hours (So he puts something there and comes back to remove it?)

And my website is not even that popular, don't know why the hacker is wasting his time and mine in being so aggressive, but he does seem highly motivated as he is doing this consistently since the last 2 months.

how on earth someone is able to upload a malware which gets downloaded automatically when an APK is accessed! Even when there is no permission for him to write to that directory!

The files might not be served from the directory you think at all but might be hidden somewhere else. This can be done by either changing the configuration of apache or some other files on the system or by injecting code into the apache process itself. For more details read about Darkleech or apache binaries with backdoors or recent attacks against wordpress sites.

  And my website is not even that popular, don't know why the hacker is wasting his time and mine in being so aggressive, but he does seem highly motivated as he is doing this consistently since the last 2 months.

Attackers are always looking for sites which are not blacklisted by anti-malware solutions. It does not matter how popular they are because they are usually just one step inside a phishing or malvertising campaign, that is the user gets directed there by the attacker.

  Apache cannot write on any of the folders now, removed all PHP scripts last week and I thought that should safeguard my website from future attacks.

I suggest that you reinstall the whole system and make sure that the usual attack vectors are closed (i.e. weak passwords, insecure wordpress installations etc). It looks like the attacker has compromised your system more deeply than you might think.


How does Android filesystem encryption work? I'm interested in encrypting my Android devices for security in the (hopefully will-never-happen) event of the phone being recovered by an unknown/unauthorized person.

How does Android filesystem encryption work and how does it stack up to other filesystem encryption solutions?

Solutions I'm more familiar with are:

TrueCrypt
dm-crypt on Linux

Furthermore, does Android filesystem encryption also protect external microSD cards, and if not, is there a way to do that in Android?

Android uses dm-crypt for disk encryption, and it is available since Android 3.

And as you would know dm-crypt works at block device layer.
So storage like YAFFS which works directly at nand flash chip level would not allow you to encrypt. But all other storage (which can be read block by block) can be encrypted.

Yes, both device and external sd cards can be protected.

Reference: https://source.android.com/devices/tech/security/encryption/


Is having theoretical access to PHI a HIPAA breach, even if no one accesses it? This is an entirely hypothetical question.

Lets say a clinic has a computer in their waiting room for checking email, surfing the web etc. while patients wait. Lets also assume whoever signed this up wasn't thinking, and this machine is just sitting on an unsecured network for the clinic, and can access patient files stored on other systems.

Lets assume however that all the users of this are well-intentioned, computer illiterate people who click on the Firefox icon and nothing else - they never actually access the patient data, they just could.

Is this, by itself, a HIPAA breach, and if so, how large of a breach is it?

Just going by the guidance on the US Heath & Human Services website:

  A breach is, generally, an impermissible use or disclosure under the Privacy Rule that compromises the security or privacy of the protected health information such that the use or disclosure poses a significant risk of financial, reputational, or other harm to the affected individual.

"Disclosure" implies that the data was disclosed to someone, which is not true in your example.   Also, it does not seem like there was "significant risk of ... harm" if nobody actually saw the data.

Another mitigating factor:  Although the terminal might be unlocked, a HIPAA-compliant patient data system will have an idle lockout for precisely this reason.  Also they will have audit trails of whether that user accessed any patient data, so you would know for certain if there were an actual breach.

Editing to add based on my comment to @Alex:

Leaving patient data on an unsecured network is a violation of HIPAA Privacy Rule and a very bad thing in general.  However, the breach does not occur until someone takes advantage of that security hole.


Is it possible to create a hardware 'Plug and Play' TOR proxy? Is there a way to use a device like a raspberrypi to create a kind of 'Plug and Play' TOR proxy?
Ideally, a device would exist with an ethernet port as input and ethernet cable or USB as output which can be plugged into a laptop or PC without any further configuration on the client PC.
The device should then automatically act like a proxy, directing all network traffic through TOR.
Note that I am not asking for a proxy which would then need to be configured on the client system (i.e. in the proxy settings of the browser) but a hardware device that guarantees that no traffic from the client system can go through the clearnet as long as it's connected in the middle between the client system and the router.
Is this possible and if it is, are there any apparent security concerns with this approach?

You could also use a travel router which supports openwrt, in most cases they have enough space to install tor. There are also cheap single board computers with two ethernet connections.
What you are looking for is called a transparent proxy:
https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy
It boils down to installing and configuring tor, enable forwarding and some iptables stuff.
Security:
There might be leaks. Also you maybe don't want to tunnel all of your traffic through tor. Tor itself has its problems too ... Depends on your threat model and why you actually want to use tor.


Is HTML5 input pattern validation sufficient (or even relevant) for client-side validation? An interesting feature of HTML5 is the <input pattern="" /> attribute, which allows the browser to validate the input field's value against a regular expression provided by the developer.

Subsequently, this binds to the field's ValidityState which can then be queried for UX feedback, to prevent invalid submission, and so on.

The server implements the same precondition validation (as well as XSRF).

Given this, is this client-side validation pattern mature and adequate, or is it for some reason still desirable to intercept the entire form and subject it to traditional per-field validation before submitting it?

From a security perspective, you need to revalidate everything on the server. This will always be the case, no matter how pretty and advanced HTML5 features become. You simply can not trust the client. You have no idea if it will follow the HTML5 rules or not. You don't even know if it is a browser.

So should you validate the whole form with your own JS client side before submitting it, even if you use the HTML5 features? From a security perspective it doesn't matter. Client side validation have zero security value anyway - see above - so from a security perspective you might just as well not bother doing it at all.

Client side validation is purely about user experience. If your own JS validation or HTML5 built in makes for the best UX is an interesting question, but it is not on topic here.


Reject requests from our tampered android apps I'm working on an Android application with few millions of users. The app has some financial|payment features. We have some public APIs and some authenticated ones (OAuth2). As a part of enhancing our security, we are currently using "Certificate Pinning".
The problem is, our app gets repackaged by some people to disable its advertisements, and unfortunately, some (unignorable number of) users install them.
We decided to reject the requests coming from these repackaged apps (not solely because of ads problem). I searched and came onto "Mobile Attestation" and SafetyNet feature in Android, but this one needs Google Play Services which rules it out.
I'm wondering whether sending the SHA256 of APK signature (using PackageManager methods) as an HTTP header and rejecting the requests with unmatched HASHs is enough for this situation? Has anyone had similar experiences? What pitfalls and gotchas could exist? We are currently only on Android but Web/iOS clients are on the plan. Could this solution be extended to them?

TL;DR: You cannot win.
What you want is called DRM, and that proved time and time again to be ineffective against dedicated users (or abusers). It increases the development cost, adds complexity, and don't solve the problem in the long run.
If you cannot rely on SafetyNet, there's no way. As defalt pointed on his comment, a tainted application will lie about its hash, because it's very easy to inspect the unmodified version and grab the hash there. You can obfuscate code to make analysis harder, but it's not possible to protect code running on the client when the client have incentives to break the protection.


How to trace script injection/infection in php app This is about a PHP7.4 based shopping platform (opencart (v3.0)).
For testing purposes I had a dummy set up at site.com/xyz. The admin page of that was site.com/xyz/admin. The login and pw for the admin page was also admin. I know, but the purpose of the dummy was just to check if a certain extensions and other things worked. And the dummy gets uninstalled/reinstalled the whole time. This live test environment is completely sandboxed in a vm/container.
Now I noticed a bunch of strange scripts got injected in to the site. Whenever I opened it up and checked the sources in the browser in developer mode, there were a number (3-4) of different adware scripts. I didn't have time to check each of them individually because I needed to reinstall a fresh copy quickly.
But obviously it is a very vulnerable setup and will hopefully get infected again soon so I can replicate the scenario. I want to understand how to track/trace the infection.
I will be checking specific opencart files/logs (and if needed I will ask about it in the relevant forum).
On security.se, I want to ask which specific server logs should I check to track how this happened. Within the live test vm/container, the opencart app is accessed via Apache24. On the main host, nginx handles connections. The only vector, AFAIK, is the admin login page. So this is probably just automated scripts doing their magic?
Edit/add: The OS is FreeBSD.

You don't specify which host o.s. you're on, so I'll assume Linux.
In this revision, I now propose the use of the built in -printf function of find if your instal supports it, as it is vastly more efficient than spawning stat numerous times (possibly for every file).
I contrast the find -printf format against the stat format in this table, in the event that your version of find doesn't provide this function, and you still need to use stat:
#.fi..st.desc.#
# %i  %i inode number
# %s  %s size in bytes
#     %o "optimal I/O transfer size hint"
#     %b count blocks
#     %B block sz
# %A@ %X time of last access, seconds since Epoch
# %T@ %Y time of last data modification, seconds since Epoch
# %C@ %Z time of last status change, seconds since Epoch
# %m  %a permissions, octal
# %P  %n file-path and -name (without starting point)
# %f     file-name only
#     %N file deref'd name (symbolic link)
# %U    user-id
# %G    group-id

vprintf='%i+|%s+|+|+|+|%A@+|%T@+|%C@+|%m+|%P+|+|%U+|%G' &&
  find ~/your_ocart_dir -printf "$vprintf"'\n'

(Note that some metadata aren't available via find - I've left these columns in so outputs produced from each version align.)
But wait, there's more! In this version, I chuck in a SHA2-384 hash of the file for extra-good measure, to be sure, to be sure. (This is limited to only files by -type f.)
find ~/your_ocart_dir -type f -printf "$vprintf"'\n' -exec sha384sum --binary "{}" \;   ## \; ensures alternate printf and sha384 lines

In my earlier version, I suggested you might stat the files and directories before the compromise occurs, to see if there are any differences afterwards?, however, this is less efficient than using the built-in features of find - I leave the stat option here for posterity, if for some reason, your version of find doesn't allow you to extract file metadata.
vstatformat='%i+|%s+|%o+|%b+|%B+|%Y+|%Z+|%X+|%#a+|%n+|%N' &&
  find ~/your_ocart_dir -exec stat --format="$vstatformat" {} \+

You would also grab the web server access logs, maybe in ~/access-logs/? Often times they come through via GET data in the query-string, which will show up in the access log.
Something else I've noticed is the attacks often pull stuff in via wget or curl, or a php function to that affect, write them where they can (ie. a writable upload directory), then call those files (you'll see this in the web server logs), then delete them. To prevent at least some of these being deleted, you could disable the unlink php function using disable_functions in php.ini. (This will let you come along later and find what code was run, however, often times the php code is obfuscated.)
Something else you can do, if you can instal things, use inotify (edit: or fswatch) to spot new files and copy them somewhere when they're first created.


Are logins with button pushes more secure than normal form logins? I recently moved to France and had to find a new cell provider, and I settled on Free Mobile. Their login page features a button-push login for the 'identifiant' (username), and a normal form field for the password.

After debugging a bit, it looks like the hidden form field for the username is a 0-10 array of the indexes of the actual buttons, which are toggled by JavaScript. So no matter the (random) order of the numbers on the buttons, the button index is what is recorded in the input. I imagine that the actual index-to-button-order array is stored on the server (unless it's in JavaScript, I'm not that good, in which case wow security by obscurity much?).

Long story short, is this login method actually more secure? For me, it doesn't seem so, and it's so annoying given that it doesn't work with my password manager.

I wonder why certain websites implement this kind of login, because it just makes my life a tiny bit more difficult (and honestly, less-secure since I keep a copy of my username on my computer). Is it actually more secure, the same security as a normal form-based login, or less secure, and why?

You almost answered your question yourself, I might just try to give some grounds for why it is actually less secure than regular log in forms.

  Long story short, is this login method actually more secure? For me,
  it doesn't seem so, and it's so annoying given that it doesn't work
  with my password manager.

There is a rule, formulated in security.stackexchange:

  Security at the expense of usability comes at the expense of security.

See here.

Called: AviD's Rule of Usability, or how I call it - security through unusability. It basically means that as soon as you decrease the usability of the security measure, security itself will decrease. We can see many such "inventions" in software world:

disallowed "paste" in the password/username field - I have made fun of it in my tweet: https://twitter.com/m1ndas/status/789984433973628928 You can also read Troy Hunts blog post on that: https://www.troyhunt.com/the-cobra-effect-that-is-disabling/
crazy limitations on password length;
strict requirements on special symbols and simultaneous neglect on password length (incentive not to use long memorable passwords).


Is it ok to allow a web application to write its own executable files? Usually I setup my Ubuntu server to have at least 2 users:

A user behalf which the web server (Apache or Nginx) runs, e.g. www-data in group www-data
A user that updates and maintains the web applications, e.g. deployer in groups deployer and www-data

A web application consists of 2 directories:

A directory for executable files (e.g. PHP or JS) served by the web server (Apache or Nginx) and a code interpreter, e.g. app
A directory for the application to write (caches, logs, uploads, etc.), e.g. storage

I setup the directories with the following permissions:

├ app          rwxrwxr-x deployer:deployer
│ └ index.php  rwxrwxr-x deployer:deployer
└ storage      rwxrwxr-x www-data:www-data
  ├ logs       rwxrwxr-x www-data:www-data
  └ cache      rwxrwxr-x www-data:www-data

The problem is that it's inconvenient to maintain the web application because it writes the files to storage with the default permission and therefore deployer can't write them. And vise versa, deployer can leave files in storage that are not writable by the application. An example of what happens after a while:

├ app                 rwxrwxr-x deployer:deployer
│ └ index.php         rwxrwxr-x deployer:deployer
└ storage             rwxrwxr-x www-data:www-data
  ├ logs              rwxrwxr-x www-data:www-data
  │ └ applogs.log     rw-r--r-- www-data:www-data # Deployer can't write
  └ cache             rwxrwxr-x www-data:www-data
    └ somecache.json  rw-r--r-- deployer:deployer # Application can't write

I can't make the application write files with other group or mode. I have to make some complex sudo setup and watch carefully the files created by deployer to maintain the application and keep it running.

Does the application self-write restriction worth the inconveniences? Is it ok (considering security concerns) to run the web server and maintain the application using a single user that can write the files both in the app and storage directories?

Some applications work around this by using ftp. They login to localhost with a given username. That’s more portable on some Webhosters that sudo.

It is a good practice if the web server cannot modify code, because this is a very common way for permanent infection. On the other hand for convenience it’s often done. If your scripts are secure (and you don’t use thirdparty modules like mailers, guestbooks, Blog or,forum software with a known weakness) then its acceptable.

Having said that, any other method like ftp or sudo has the same problem if the credentials are stored reachable for the web server.