|
Haven't used it myself but I found out about https://www.sharklasers.com/ the other day. (EDIT: Probably doesn't work with attachments though. Meh. Still a neat link?)
|
#
¿
Dec 31, 2016 16:25
|
|
|
|
| # ¿ Apr 26, 2024 16:53 |
|
|
I've been really enjoying working through https://www.crypto101.io/ myself.
|
|
#
¿
Apr 19, 2017 06:20
|
|
|
Can't find the source for that screencap on Cliqz's website; quick glance at various discussions about the acquisition seem mixed instead of soundly negative; proponents point out things like how Mozilla has invested in Cliqz and Cliqz' technology is open source, both of which appear verifiable. So that gives me two questions: a) is or is not Cliqz actually a slimy tracking company, and b) if there's proof they are, what are the other alternatives (pay or free) for people wanting Safari ad blocking? (... is 1Blocker legit, for example?) Literally asking for a friend (I use Chrome w/ uBlock Origin + Disconnect), I'd have a hard time getting them to switch off of Safari unfortunately.
|
|
#
¿
Apr 30, 2017 23:37
|
|
|
flosofl posted:Why not just recommend they use uBlock Origin for Safari? Because last time I looked, it wasn't available for Safari. But I see that changed about 5 months ago, so, happy day! Thanks! astral posted:https://cliqz.com/en/support -> company info -> how does cliqz earn money? Well that'll teach me to look under 'About' instead of 'Support' 
|
|
#
¿
May 1, 2017 02:48
|
|
|
Yup, Vault seems to have a lot of the mindshare in that space lately. I had to look into this semi recently myself (in a "likes to use open source, is cloud hosted" context, FWIW) and threw a bunch of bookmarks into Pinboard: https://pinboard.in/u:bitprophet/t:secretsmanagement Some of those are articles or adjacent resources; I'd say the big names to look into are Vault, Torus, Keywhiz, Cerberus, or $CLOUD_PROVIDER_SOLUTION if you're on a single cloud, like Amazon's KMS (which has dozens of projects built on it or can be used directly.) I haven't gotten super deep into Vault yet, practically speaking, but what I have used has been pretty solid and I like a lot of the overall design, the number of secrets backends, etc. It definitely seems like the solution to beat if it fits your parameters.
|
|
#
¿
May 10, 2017 00:32
|
|
|
Domain Name Stout Transmission Control Pilsner Read-Ahead Lager us-1-yeast Test Dubbel
|
|
#
¿
Nov 2, 2017 23:32
|
|
|
Figure the brewery name could be Berkeley Suds Distribution?
|
|
#
¿
Nov 2, 2017 23:59
|
|
|
Proteus Jones posted:this is for all the people who self-owned by "testing" the exploit like idiots without thinking through the consequences. Security is hard enough without giving users more reasons to dislike/distrust us wonk types! quote:However the fact Root can access macOS remotely via VNC/Screen Share is asinine. If you have "Remote Access" enabled for ssh/sftp, make sure this line is in your /etc/ssh/ssh_config under the "Host *" section toward the bottom. Presumably you meant to modify /etc/ssh/sshd_config, but at least as of my Sierra system, PermitRootLogin defaults to prohibit-password which should mean users are not at risk for this problem via SSH unless they manually edited the file to say yes, in which case I rescind my "for the users!" spiel above and that person probably is an idiot 
|
|
#
¿
Nov 29, 2017 07:12
|
|
|
Less Fat Luke posted:Actually I'm trying to confirm this but I'm almost certain the newest version on Windows does not support a local vault except when importing one to their cloud service. This was apparently a temporary problem (rather, they simply had not implemented it yet, period, for the Windows version which was a new codebase) that they're working on fixing for 1Password 7. See last few paragraphs here https://blog.agilebits.com/2017/08/01/1password-6-7-for-windows-a-feature-buffet/. Rest assured that a poo poo ton of users are keeping close eyes on them re: their promises to continue supporting local vaults in general, for a long time. They clearly implement fun new shiny things for the server-based feature set first nowadays, but they haven't quite yet gone over the line to clear & obvious neglect of the local-only use case. If/when they do, there will probably be a pretty big exodus to...who knows where. (Or a big shitstorm & walking-back, who knows.)
|
|
#
¿
Feb 26, 2018 22:47
|
|
|
Space Gopher posted:On that note, does anybody have good resources on securing Jenkins and friends when they're used for deployment automation in web apps? It's always worried me that a lot of these systems get godlike permissions (especially w/r/t AWS/Azure/GCP accounts!) but tend to have lovely security. Do you mean specifically hardening the Jenkins servers/services themselves, or securing the overall workflow? Your 2nd comment implies you're at least thinking about the latter, in which case you should take a look at secrets management systems like Vault. Having a tool in charge of distributing & rotating secrets, and enforcing that they are on short-lived leases, is a big step up from "meh I just dropped my, or a similarly long-lived, AWS API secret into Jenkins' config, now an attacker gets to be god forever if they break in". Instead, they only get to be god for, say, 15 minutes, or an hour, instead of retaining those privileges for weeks/months until they're ready to leverage them. Related, it doesn't require use of a secrets store (tho they often make the process easier) but another relatively low hanging fruit option is to follow principle of least privilege and only give Jenkins API keys that do exactly and only what it really needs to do. You may think "ugh, my deployment needs instance creation, listing, modification and termination, plus all the same for volumes, plus most of that for AMIs, and ... being explicit is too much work, I'm just gonna give it a full admin role." Resisting that temptation and handing out only what you need, means that if Jenkins starts working for the enemy it doesn't have e.g. the ability to assign admin privileges to other users, or destroy backups, or etc. An attacker that can nuke instances is one thing, an attacker that can lock you out of the system or create a quietly unnoticed backdoor is much worse.
|
|
#
¿
Feb 28, 2018 18:58
|
|
|
First quoted Twitter user found that Trustico's website is executing untrusted user input in the shell (entering a "domain name" of $(curl myserver/url) results in that fella's myserver site getting curl'd). Second quoted Twitter user piggybacks on that to prove, by updating the injected shell command to include the output of another subcommand (id, which spits out the running user's name and UID) that not only is Trustico executing untrusted user input...they're executing it as root. All the facepalms. EDIT: one more facepalm, courtesy of me using code instead of fixed
|
|
#
¿
Mar 1, 2018 20:21
|
|
|
Proteus Jones posted:walking away and leaving them physically unsecured (Kensington Locks don't count as "physically secured"). When you're out in a public space, does anything short of "on your person or otherwise within reach/sight" count as physically secured?
|
|
#
¿
Mar 22, 2018 17:54
|
|
|
I mean, they're actively hostile to developers using their api, such as the recent "API apocalypse" which has made third-party clients noticeably worse. Around the same time I believe there were related changes that make things like (non-hostile, useful/artful/entertaining) bots much harder to create/operate. They basically have no idea why people enjoy(ed) their platform and are happily relying on the social graph/snowball effect to keep users around while they tighten things up to make it more advertiser-friendly. I don't have useful anecdata on the infosec side of things, though.
|
|
#
¿
Oct 1, 2018 01:48
|
|
|
apseudonym posted:What, did they share state machine code between client and server? How do you even gently caress that up Making matters worse is that these libraries tend to start out client-only and remain client-focused even after somebody adds server-side functionality, since most SSH servers are either OpenSSH or some random embedded server (though I bet libssh powers some of the latter  ).It's a nice recipe for organically grown bugs of this nature, and then the server-specific use case tends to languish until some enterprising security researcher goes "hm, barely-used code that is pretty drat important for anyone actually using it? I bet there's bugs!". Proof: Paramiko had this literal exact same bug reported a few months back, and that's its second server-side CVE in the last year. (AFAIK libssh was not a port of Paramiko, though I suppose it's possible.) The only defense I have for the original authors of these codebases is they're both a decade or more old (...the codebases, not the authors) and as bad as proactive security coding is today, it was even worse back then.
|
|
#
¿
Oct 17, 2018 06:15
|
|
|
Boris Galerkin posted:So what does that gently caress up mean for me? A person with Linux machines running ssh (w/ public key access only)? Should I just assume all my poo poo is out there now or …?
|
|
#
¿
Oct 17, 2018 08:03
|
|
|
Powered Descent posted:remove the hard drive. Install your favorite Linux (encrypted, of course) to an SD card or USB stick
|
|
#
¿
Nov 1, 2018 23:16
|
|
|
evil_bunnY posted:LiveCDs/SDs are a thing because logs are a thing. It’s no use going to a random network if you then carry evidence of having connected there. It’s just easier to dispose of physically smaller media as well. Rufus Ping posted:What's the point of the whole drat post 
|
|
#
¿
Nov 2, 2018 01:04
|
|
|
To be fair, aside from JavaScript's inherent language issues & the problems it gains from popularity & low barriers to entry (hi PHP!) this sort of thing could happen to any other open source project. Of course, JS also has an extra cultural weakness, in the form of significantly larger attack surface for "lol you depended on poo poo you didn't even know existed": https://twitter.com/greybaker/status/1064861297152585728
|
|
#
¿
Nov 27, 2018 22:12
|
|
|
I saw an interesting take on the AA bill which was (IIRC) that organizations have always been at risk from state-level actors compelling employees to do their bidding one way or another, and therefore if your threat model didn't already include that sort of attack, this doesn't change things. As a decidedly non-expert individual, I'm not sure I entirely buy that reasoning – surely the fact that said compulsion can now be effected entirely legally means it's significantly more likely than when it required illegal/extrajudicial shenanigans?
|
|
#
¿
Dec 13, 2018 20:35
|
|
|
Achmed Jones posted:just to be clear, though, thunderbolt isn't what chargers use - that's lightning. also, apple names are bad. but i mean s/charger/display or whatever That said it's more confusing nowadays with Thunderbolt 3, which uses USB-C form factor, and the fact that you can use it to talk purely data to eg drives. I don't think Thunderbolt 2 carried power (eg when I had a Thunderbolt 2 dock setup the laptop still needed separate power connection) but I'm too lazy to look it up. bitprophet fucked around with this message at 22:29 on May 11, 2020 |
|
#
¿
May 11, 2020 22:25
|
|
|
|
| # ¿ Apr 26, 2024 16:53 |
|
|
Thought this was the Infosec thread not the Poorly Roleplaying 1990s Cyberpunk Themes thread?
|
|
#
¿
Jun 25, 2020 01:55
|
|