Hacker Newsnew | past | comments | ask | show | jobs | submit | raesene2's commentslogin

Doesnt look like that comment came from nat? Username for that comment is naikrovek not natfriedman


Some people have dyslexia, or skim too much and don't go past the first letter, I guess.


Yeah somehow I got the names mixed up and can't delete now.


Or Robert Seacord’s Effective C


Shame they didn’t include traffic to security.stackexchange.com . I would have thought that would show a more noticeable change. Also would be interesting to see what tags there show the biggest increases


Not really. They can be used to replace one element of the docker stack, runc


“Why bother posting this?” - that’s easy, because it might hit the front page of HN and someone from Google might see it and actually apply human reasoning to the problem.

And then it might get resolved well...


Fair play, it is getting late :)


For uk banking systems it is very likely that the passwords are stored symmetrically encrypted with the key stored in an HSM (based on my experience working as an IT security consultant in UK banks).

Whilst limiting passwords isn’t good, with storage in that way i’m nt sure I see many viable attacks on a 12 char random password.

Online brute force will hit the lockout on the site, and even assuming you could get access to the server hosting the encrypted passwords and HSM you cant decrypt the passwords (unless they have made some horrific setup errors), so the only offline attack is to try and brute force the encryption key, which is unlikely to be easy.


I'm not familiar with HSM [1] but is any internal attack possible, like bribing an employee or getting a trojan on somebody's computer inside the bank?

This is a HSM for people like me a few minutes ago:

[1] https://en.m.wikipedia.org/wiki/Hardware_security_module


So obviously in cases of personnel threats you need different controls.

On HSM setups I've seen the keys are under dual-control (i.e. two different people have half the key and in the event that it needs re-entered, both have to enter their keys independently), along with other general controls (hiring background checks etc)

That's not to say it's impossible, just there are controls in place.

Now in all this I'm not trying to suggest that bank security is perfect, it's obviously not, but that particular concerns about password strength and threats of attack on this could be misplaced, due to lack of understanding of the controls in place.


If you base off alpine, you can get useful containers quite a lot smaller than 100MB.

One example i use is an agent i deploy to kubernetes clusters to do some security scanning. The scripts are ruby and the image clocks in at 9MB compressed https://hub.docker.com/r/raesene/kaa-agent/tags/


On the same note I did a mariadb container that is ~12mb: https://hub.docker.com/r/jbergstroem/mariadb-alpine/

If you're into go, it's not too hard to get very small (<5mb) shippables by statically compiling against musl and using upx. Here's a somewhat scrubbed Dockerfile for a gRPC/rest service I use at work: https://gist.github.com/jbergstroem/680cb7db6f90319dcd7666f3...


5mb still sounds like a lot, considering you could squeeze Linux 1.3 on a 1.44 mb floppy with a (compressed) rootfs... I mean does the runtime really do that much more than a full (although old) os kernel and a C library/runtime and apps?


The entirety of Debian 0.97 (kernel, userspace, packages) fit on two floppies back in 1994 :P


For that I reckon you'd have to file a bug with golang.


Yes, I use Alpine for a lot of my other containers. I love the simplicity of the package manager as well.


Alpine's package manager has the great property that you don't need to update the index in order to fetch a package IIRC; the whole `apt-get update && apt-get install && <cleanup apt-cache>` dance is quite tedious in debian-based Docker containers.


No, you still need to, but there's a compact syntax for it that will update and discard the index in a single 'add' command. It's unavoidable - somewhere some querying is happening in order map the package name/ver to a download link.


I find the haproxy (alpine) Dockerfile a great example on how to tender to container file-size. It uses the syntax you're referring to, temporary build virtuals (should be multistage today I guess) and static linking: https://github.com/docker-library/haproxy/blob/2d393f2b59824...


Awesome example, thanks. We've been starting using different Dockerfiles for prod and dev. For prod we want tiny images, but for dev the caching of layers is more important for frequent rebuilds. Such balance all the time :sigh:


Have you tried pocket? I used to keep a load of bookmarks but the problem was that after a while many of the source urls would die off. So something like pocket is very handy as it takes a copy of the page you're interested in.


Why pocket when we have opensource wallabag that you can either host yourself[1] or use as a service[2] ?

IIRC pocket has had some serious vulnerabilites exposed.

[1]: https://wallabag.org/en [2]: https://wallabag.it/en


Pocket might get better integration since it was recently acquired by Mozilla. Fingers crossed...


Pocket had a great integration with Firefox when it was an extension. Then they decided to integrate it into the browser and ironically it end up being a piece of shit that was not more functional than a bookmarklet. Not only that but they also removed the original extension from add-ons site so you have had to use the half assed built-in implementation.


Well there is, but it's not cheap. You get a trusted third party to Audit you and publish the result of their Audit, something similar to a SAS70.

It's not a perfect solution but it's an option to consider


fair point – this is something we consider doing before expanding to b2b market. but:

my day job is in ecommerce (I work as a product manager at FastSpring) and I used to work on CleanMyMac at MacPaw – had to work with trust in both. it's somewhat unexpected but people who are buying software for themselves usually don't care about PCI compliance, audits, and other artifacts of "institutional validation". they care about a "norton secured" badge, proper language, recommendation from a person they know, a review at the website they read, "that green thing with the lock in my browser".. we're now at the phase where we are trying to find the right combination.

just to be clear – it's very different from project to project and depends on the audience. what I'm saying is that we're making decisions emotionally mostly based on our prior experience and rely on internal "thermometer" to tell us if what we're seeing is trustworhty.


When dealing with sites where high trust is required I think people would much rather see an independent audit or compliance with a (legit) security accreditation than a Norton badge, however, most of the time this is not offered, so we make do with the crappy badge, a recommendation, or gut instinct.

Having said that, I deal with independent audits in my job, and they're not all that reassuring.


Pardon my ignorance or perhaps its just that I've become jaded, but outside of circumstances with dire/sever consequence such as laws, regulations, etc how does an independent audit (legit accreditation or not) verify what happens after the audit is done and the auditors long gone?

How does an independent audit detect out of band taps (swapping binaries, re purposing archives/backups, mirroring, etc) on infrastructure the auditor wasn't monitoring before the audit? logs? but more importantly amortized or not the customer eventually pays for all this activity that at the end of the day is more fluff than substance (in terms of what the customer can actually verify) In the end doesn't all this come down to just another form marketing?

Please note, that I recognize that there are many scenarios where an independent audit would add value. I just don't think it adds anything that social validation doesn't already add when considered from the perspective of a consumer to whom the infrastructure behind the service is unavoidably opaque.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: