00:00:00.299
foreign
00:00:12.679
I hope you're all having a fantastic
00:00:15.059
Wednesday so far thank you for joining
00:00:17.220
and listening
00:00:18.779
um hopefully you're excited to learn a
00:00:20.580
little bit about ruby gems MFA and its
00:00:23.640
past present and future I'm Jenny I'm a
00:00:28.140
developer at Shopify
00:00:30.480
under review dependency security team
00:00:33.440
where we help secure its Ruby supply
00:00:36.180
chain I also recently became a
00:00:38.760
maintainer on rubygems.org which is kind
00:00:41.579
of exciting
00:00:43.260
um what's
00:00:45.000
even more exciting is that this is my
00:00:48.000
first ever time get giving a talk at a
00:00:50.640
conference and I'm so glad that rubycon
00:00:53.160
mini is the place where I'm doing it
00:00:57.480
um so just recently some of you may have
00:01:00.180
seen this in June ruby gems announced
00:01:03.300
that they're requiring
00:01:04.820
owners of popular gems to have MFA
00:01:08.040
enabled some folks from Shopify and I
00:01:10.860
helped create this change so today I'm
00:01:13.740
just going to tell the story on how this
00:01:16.020
policy came about this includes why is
00:01:19.080
MFA even important and why do we need it
00:01:22.380
for ruby gems accounts
00:01:24.420
how do we how did we implement the
00:01:26.759
policy this includes like figure out the
00:01:29.159
details and getting consensus from the
00:01:31.439
community and lastly what's next in
00:01:34.500
store uh in the next couple months and
00:01:37.079
Beyond
00:01:38.220
with that being said let's dive right
00:01:40.619
into it
00:01:42.299
um so a bit of a random question raise
00:01:44.880
your hand if you ever heard of the term
00:01:47.579
goiter and know what it is
00:01:50.700
oh okay we got a couple got it give
00:01:53.820
yourselves a pat on the back
00:01:55.820
for those who don't know uh goiter is a
00:01:59.340
condition that makes your thyroid gland
00:02:01.520
abnormally large which makes your neck
00:02:04.740
appear a bit swollen the cause of this
00:02:08.340
condition is iodine deficiency
00:02:10.640
apparently I found out yesterday I've
00:02:14.040
been saying that word wrong
00:02:16.020
some people say iodine but I say I
00:02:20.099
didn't so
00:02:21.440
bear with me when uh when I say that
00:02:25.520
iodine is essential for thyroid hormone
00:02:28.860
production and goiter can be the result
00:02:31.260
of this insufficient production of the
00:02:33.959
hormone
00:02:34.980
up until the past Century iodine
00:02:37.980
deficiency was a global public health
00:02:40.140
issue in ancient times the treatment for
00:02:44.040
goiter was consuming seaweed or sea
00:02:48.120
sponge
00:02:49.400
it wasn't until the 19th century that
00:02:53.459
the element iodine was discovered and
00:02:56.459
found to be the Cure it was then found
00:02:59.220
that iodizing salt was an effective way
00:03:01.860
to add iodine into people's diets as a
00:03:05.940
simple preventative measure since then
00:03:09.920
120 countries have made salt iodization
00:03:13.640
mandatory and areas that made this
00:03:16.680
mandatory like Canada has removed the
00:03:19.620
need to monitor iodine levels in the
00:03:22.440
population since it removes so much of
00:03:25.260
the risk they don't need to think twice
00:03:28.019
about this being an issue
00:03:33.840
okay so why have I been talking about
00:03:37.099
goiter in the last few minutes
00:03:40.500
this is rubycon and not goiterkov but
00:03:45.840
there are loads of similarities between
00:03:49.440
um goiters and supply chain attacks
00:03:52.799
there has been an exponential increase
00:03:55.260
in software supply chain attacks over
00:03:58.019
the past few years it's been reported by
00:04:00.659
sonotype that there's an average
00:04:02.459
increase of
00:04:04.760
742 percent year over year in the past
00:04:08.400
three years
00:04:09.540
for those who don't know the supply
00:04:12.599
chain is basically all of the components
00:04:15.900
that help make a piece of software
00:04:18.479
a supply chain attack is when a
00:04:21.000
malicious actor attempts to attack
00:04:22.979
specific components in the supply chain
00:04:25.740
so some examples of this is an
00:04:28.979
undercover employee pushing malicious
00:04:31.440
code to Maine by passing any code
00:04:33.660
reviews
00:04:35.340
um someone getting access to the Ci or
00:04:39.180
deployment infrastructure and inserting
00:04:41.759
a malicious code there or the one that
00:04:44.940
we're most interested in is your piece
00:04:47.940
of software using a package or gem with
00:04:51.300
malicious code
00:04:53.100
the second most common attack is
00:04:56.820
account takeovers the first one is typo
00:05:00.960
squatting but I won't be going into
00:05:02.759
detail about that if your enlisted
00:05:05.040
interested in learning more I highly
00:05:07.080
recommend Ashley Pierce and Betty Lee's
00:05:09.660
railsconf talk gem install what can go
00:05:12.120
wrong and mashes Rubik on how to take
00:05:17.340
over a ruby gem but back to account
00:05:20.820
takeovers if a malicious actor gets a
00:05:24.600
hold of your rubygems.org account by
00:05:27.360
cracking your password that might be
00:05:29.940
reused they are able to sign in which
00:05:33.300
produces a key that has the ability to
00:05:36.300
publish gems as you can see here
00:05:39.660
or if the attacker has a hold of your
00:05:42.780
key through some other means like your
00:05:45.240
git history they are able to set an
00:05:47.699
environment variable gem host API key to
00:05:50.940
authenticate as you
00:05:52.860
they can then release a new version of
00:05:54.900
the gem with malicious code by
00:05:57.139
downloading the gem contents inserting
00:06:00.600
the code in the file of their choice
00:06:04.500
bumping the gem version
00:06:07.440
um
00:06:08.400
building the gem by running gem build
00:06:10.860
which packages all of the contents into
00:06:13.380
one file and pushing that package gem up
00:06:17.160
to Ruby Jones
00:06:18.720
anyone that installs this gem is
00:06:21.060
affected
00:06:22.440
um and an example of this is the rest
00:06:24.720
client gem in 2019 someone took over the
00:06:28.860
job maintainers account and insert a
00:06:31.979
code that would execute code from a
00:06:35.280
paste bin URL
00:06:37.199
in that paste bin a file a lot of bad
00:06:40.680
things are happening first of all it
00:06:43.680
sends the URL of the effective host to
00:06:46.919
the hackers define endpoint
00:06:50.100
um it will also send all of your secrets
00:06:53.340
to that Hacker's defined endpoint
00:06:57.440
it'll also set and if your app has any
00:07:01.199
clients I'll send over the user uh the
00:07:04.440
email and passwords by overloading the
00:07:07.680
authenticate method in identity and
00:07:10.800
worst of all if the attacker sends a
00:07:13.800
cookie that matches the regex defined
00:07:16.259
the contents of the cookie will be
00:07:18.660
executed essentially the that hacker can
00:07:21.720
do whatever they like
00:07:23.940
but rest client isn't the only gem she
00:07:26.940
strong password was taken over and had a
00:07:30.840
similar injection by evaluating from a
00:07:34.080
paste bin file and that evaluates
00:07:38.280
um contents of a certain cookie as well
00:07:45.560
and this is just a few out of many
00:07:48.780
instances in Ruby but this also happens
00:07:51.780
in other package ecosystems like npm and
00:07:55.740
Pi Pi
00:07:57.479
there is a simple preventative measure
00:08:00.240
to solve account takeovers though feel
00:08:03.419
like you might know what it is if you do
00:08:05.819
you can say it with me it's
00:08:08.780
multi-factor authentication oh that
00:08:11.759
that's really good I'm impressed
00:08:14.639
um also known as MFA adding another
00:08:17.400
Factor during authentication makes it
00:08:20.340
harder for someone else to sign in and
00:08:23.340
act like you and after the incidents I
00:08:26.879
mentioned gem maintainers rotated
00:08:28.680
passwords and enabled MFA
00:08:32.459
um I set out to start this that there's
00:08:34.860
many similarities between goiters and
00:08:37.380
account takeovers well what are they
00:08:39.719
Jenny
00:08:41.159
um they're both a widespread problem
00:08:43.320
iodine deficiency was a global health
00:08:47.000
issue and supply chain attacks are a
00:08:50.459
growing issue in the world of software
00:08:53.100
for both instances there's a effective
00:08:56.339
and simple preventative measure so
00:08:59.519
iodization and multi-factor
00:09:02.279
Authentication
00:09:04.920
um though for both of these counter
00:09:06.300
measures this requires changes from a
00:09:09.000
certain group of people producers of
00:09:11.399
salt must spend money to buy equipment
00:09:14.040
hire staff and materials or for MFA
00:09:17.339
package maintainers might need to spend
00:09:20.160
more time to publish and maintain their
00:09:23.040
gems and that could be kind of
00:09:25.019
burdensome
00:09:26.279
so why Implement laws and create a
00:09:29.940
policies for both these cases the answer
00:09:32.820
is simple the cost to prevent these
00:09:36.000
issues is significantly smaller than the
00:09:38.640
cost to deal with them when people get
00:09:40.980
sick because they're iodine deficient
00:09:43.500
they need to seek medical help which is
00:09:46.080
costly on the patient and the Health
00:09:48.240
Care system when malicious packages are
00:09:51.420
released time and effort needs to spend
00:09:53.820
on removing the gem drafting your
00:09:55.980
advisory and communicating the incident
00:09:58.320
this can have a more Dental mental
00:10:01.680
effect on consumers of the gym they need
00:10:04.440
to make sure that their application is
00:10:07.680
safe by rotating their secrets if they
00:10:11.399
have clients they might need to say that
00:10:13.920
there might be a breach somewhere and
00:10:16.019
downgrading the gem
00:10:19.320
hopefully I convince you the importance
00:10:21.959
of creating an MF MFA policy on Ruby
00:10:25.740
Jones accounts now
00:10:28.320
um
00:10:30.060
in this next portion I'll be going over
00:10:32.339
how a policy like this is made
00:10:41.640
but while we're talking about MFA let's
00:10:44.339
take a second and talk about the state
00:10:46.560
of MFA our ruby gems before any policies
00:10:51.180
were enforced
00:10:52.740
so Ruby Jones currently has MFA in the
00:10:56.100
form of time-based one-time passcodes or
00:10:58.880
totp or OTP which you can install an
00:11:03.660
authenticator app like Google
00:11:04.980
Authenticator or one password once
00:11:08.760
enabled there's three levels for UI only
00:11:12.959
you'll be required to enter a code when
00:11:16.440
you log into your account on the web
00:11:18.839
for UI and John sign in along with UI
00:11:22.440
only you'll be required to enter OTP
00:11:25.380
code when you publish your Gem and for
00:11:28.079
UI and API along with signing in like a
00:11:32.579
UI and Gem sign in you'll also need to
00:11:36.060
enter a one-time passcode for all
00:11:39.000
privileged actions like gem pushes you
00:11:41.880
can see here some other privileged
00:11:44.700
actions include yanking and Gem version
00:11:46.740
and managing owners of your gem
00:11:50.220
you may be thinking
00:11:52.800
um why are there so many levels it's
00:11:55.260
kind of confusing
00:11:57.120
um the main reason is that continuous
00:12:00.060
integration and deployment systems make
00:12:02.700
it harder to
00:12:04.519
heart I can't really uh MFA and at
00:12:09.360
Shopify we use the ship at engines to
00:12:12.300
ship it engine gem to push our gems so
00:12:15.899
after clicking the deploy button it'll
00:12:18.300
trigger a script to build a gem add and
00:12:22.680
you get tags and publish it to ruby gems
00:12:26.220
there's no way to enter an OTP code in
00:12:30.000
this workflow other than ship it a good
00:12:32.940
portion of maintainers also use GitHub
00:12:35.399
actions
00:12:37.019
and along with like account level mfas
00:12:39.540
one Nifty feature of ruby gems is that
00:12:42.779
gem maintainers can Define that all
00:12:45.480
owners of your gem
00:12:47.480
must have MFA enabled by defining the
00:12:51.420
ruby gems MFA required field to true in
00:12:55.079
your gems gem spec
00:13:00.959
okay so now that you know a little bit
00:13:04.560
about how MFA Works in ruby gems let's
00:13:07.740
go back and talk about how this policy
00:13:10.620
came about
00:13:12.060
there are many things to think about
00:13:14.399
when figuring this out looking back I
00:13:16.980
would categorize this into three main
00:13:19.620
areas
00:13:20.760
how many people should we be required to
00:13:24.000
enable MFA
00:13:25.740
what does MSA enforcement look like and
00:13:30.899
um
00:13:31.980
how do we ensure that this change is
00:13:34.980
seamless for Gen maintainers
00:13:37.680
that's a lot of decisions to be made but
00:13:40.500
how do we make sure that the decisions
00:13:43.139
that are made are right for the
00:13:44.760
community
00:13:45.720
well we got the community to help us and
00:13:49.019
weigh in
00:13:50.339
like many open source projects and
00:13:53.220
package managers ruby gems has a refresh
00:13:57.420
for comments process or RFC for large
00:14:00.540
and fundamental changes for ruby gems
00:14:04.100
their rfcs live in a GitHub repository
00:14:07.560
and before opening a formal proposal
00:14:10.740
many open uh discussion as an issue to
00:14:14.579
gauge interest in ideas
00:14:16.620
my colleague Jacques opened an issue
00:14:19.320
with these questions to get initial
00:14:21.360
thoughts the feedback was overall really
00:14:23.700
positive it validated the views that the
00:14:26.519
team had and people gave good
00:14:28.560
suggestions for the first draft of the
00:14:31.320
proposal and I'll be mentioning them as
00:14:34.440
we bring up those three main areas that
00:14:37.260
I brought up
00:14:39.000
first off how many people should be
00:14:41.279
required to enable MFA
00:14:43.980
well of course the north star of this is
00:14:46.620
all users however it might not be best
00:14:49.320
to do so immediately
00:14:51.380
an iterative approach may be better as
00:14:54.899
we can learn from each iteration so a
00:14:58.380
better question would be how many users
00:15:00.540
should we enforce MFA first
00:15:03.560
it was agreed upon that these gem
00:15:06.720
maintainers that should be enforced
00:15:08.880
should be the ones that have the biggest
00:15:11.220
impact if taken over a good measure for
00:15:15.420
that in ruby gems is the total gem
00:15:18.660
download count luckily Ruby jams shares
00:15:22.019
a Daily Dump of gem or information for
00:15:24.420
anyone to use and using data from last
00:15:27.300
year there was 10.6 billion downloads in
00:15:31.320
ruby gems in its lifetime I query for
00:15:34.920
the number of total downloads given the
00:15:37.620
X number uh top X number of gems where X
00:15:42.060
is just numbers I pulled from there I
00:15:45.779
found that the increase in number of
00:15:48.600
downloads drops after the top 100 gems
00:15:52.620
it covers more than a third of total
00:15:56.279
downloads with uh which out of 100 and
00:16:00.420
more than 180
00:16:02.820
000 gems was kind of shocking to hear
00:16:05.639
I recently went back to grab more data
00:16:08.100
points and plotted it on a graph and
00:16:10.260
such a beautiful curve
00:16:12.360
um you can see that
00:16:14.480
after at the top 10 000 gems it covers
00:16:19.079
most of
00:16:20.420
ruby gems as total downloads
00:16:25.139
nope
00:16:29.220
okay next question what does MFA
00:16:33.300
enforcement look like for a user
00:16:36.360
that might be a simple question on the
00:16:38.339
surface just make users enable MFA right
00:16:41.660
but we need to decide on what MFA level
00:16:45.540
do you require users to be at and what
00:16:49.740
actions should we protect if users don't
00:16:53.519
have MFA enabled but is required to
00:16:57.300
for the first one we mentioned that UI
00:17:01.740
and API is the best along with needing
00:17:05.100
to MFA to create an API key to actually
00:17:09.839
push a gem you also need to enter a code
00:17:12.360
as well
00:17:13.620
for UI and Gem sign in to sign in and
00:17:17.520
create a key you need to MFA but if
00:17:20.699
someone already has access to a key they
00:17:23.220
can publish a gem without needing to MFA
00:17:26.419
UI and Gem sign in was selected because
00:17:29.820
of the continuous integration case I
00:17:32.700
mentioned before
00:17:34.340
but for that use case we received some
00:17:37.440
suggestions from the discussion to add
00:17:41.940
more scoping features to API Keys like
00:17:45.320
enabling MFA on specific keys so if you
00:17:48.960
have a few keys that use for automation
00:17:52.620
you don't want to turn MFA on for those
00:17:55.020
but if you do some manual maintenance
00:17:58.080
you can enable MFA for those keys
00:18:01.799
another one is scoping keys to a
00:18:04.260
particular gem so sometimes I mean here
00:18:08.340
will would just do maintenance on one
00:18:11.100
gem so they don't really need access to
00:18:13.320
all of them and adding expiries to a
00:18:17.820
sale key so they'll be removed in a
00:18:20.340
certain period of time
00:18:22.460
After figuring out what level we want to
00:18:25.440
enforce MFA at it's time to decide what
00:18:28.320
actions should we be
00:18:30.200
protected if users don't have MFA
00:18:33.240
enabled but is required to we decided to
00:18:37.100
protect all authentication authenticated
00:18:40.679
pages on the web the reason why we went
00:18:43.919
with this approach is that
00:18:46.940
if there was a change needed to be on my
00:18:50.039
account I would like that to be clear so
00:18:52.740
when someone signs in all of those pages
00:18:55.559
would not you wouldn't be allowed to
00:18:58.620
access
00:18:59.580
for the command line it made the most
00:19:01.919
sense to protect actions that required
00:19:04.140
and OTP code for those actions those
00:19:08.100
actions modifies your account in some
00:19:11.340
way which is the things we want to
00:19:13.500
protect the most
00:19:15.419
okay
00:19:16.380
so we're down to the last question how
00:19:20.700
do we make make requiring MFA the most
00:19:24.299
unsurprising and seamless change
00:19:31.080
like deprecation of features
00:19:34.140
um it's good practice to allow some time
00:19:36.059
for users to onboard before we make any
00:19:39.000
breaking changes not saying that
00:19:41.460
everyone would do it before I'm guilty
00:19:43.740
of not updating my Mac until my company
00:19:46.860
doesn't let me doesn't allow me to do
00:19:50.100
anything that's nice it's nice to let
00:19:53.340
people have the time to onboard first
00:19:55.320
before blocking any
00:19:58.740
um gem pushes if they don't have MFA
00:20:01.140
enabled
00:20:02.640
but that time wouldn't actually do
00:20:04.799
anything if users don't do uh if jumping
00:20:07.919
here is not do not know about it to do
00:20:11.160
this during this time period job
00:20:13.679
maintainers will see a warning
00:20:15.059
Wednesdays first sign in and on certain
00:20:18.120
actions on the command line
00:20:20.340
okay cool
00:20:21.980
unknowns
00:20:23.539
are now known and an RC was drafted with
00:20:28.200
what was talked about for the community
00:20:30.179
to provide feedback on
00:20:32.640
there was some great feedback
00:20:34.380
suggestions and refinements to make this
00:20:36.960
policy better one of which is that the
00:20:40.380
number of gems
00:20:42.140
that a number of the top num uh top 100
00:20:47.059
gems can change over time so if your gem
00:20:52.160
100 and you become gem 101 all of a
00:20:56.220
sudden you wouldn't be required to have
00:20:58.980
MFA enabled well and on the other hand
00:21:02.760
if your job becomes more popular if your
00:21:05.640
gem is Gem 101 and becomes gen 100 all
00:21:10.140
of a sudden you are required to have MFA
00:21:13.559
enabled Joseph Ruby Jones maintainer
00:21:17.039
suggested that we use that download
00:21:19.260
thresholds as the metric so once a gem
00:21:22.679
surpasses a certain threshold they'll be
00:21:25.200
required to enable MFA and once they are
00:21:28.320
close to that threshold we can notify
00:21:31.080
them that they'll be required to enable
00:21:34.080
MFA soon I recommend them to enable it
00:21:37.380
now now
00:21:38.780
another piece of feedback what received
00:21:41.640
was surrounding the communications
00:21:44.760
some users might not use the platform
00:21:46.919
during the transition period and see
00:21:50.460
that they need to enable MFA
00:21:53.059
Aditya a ruby Jazz maintainer mentioned
00:21:55.919
that it's good practice to also post a
00:21:59.460
blog post send emails and share it on
00:22:02.520
social media
00:22:04.620
um along with logistical feedback there
00:22:07.500
was just an underlying hesitancy to
00:22:09.720
actually push this forward there were
00:22:12.360
some things that ultimately leave the
00:22:15.000
uneasiness with this type of change
00:22:18.900
um the easiest thing to do is to listen
00:22:21.419
there are valid concerns to the pushback
00:22:24.360
like um it's gem maintainers are often
00:22:29.039
volunteers and that we don't want to add
00:22:31.860
more uh that's they are volunteers that
00:22:34.799
spend their free time maintaining their
00:22:36.900
the gems and we don't want to add more
00:22:40.020
time and cause a burden to them this
00:22:44.700
makes a lot of sense and listening to
00:22:47.039
these concerns we can address them and
00:22:49.200
help look at help them look at the
00:22:52.260
bigger picture though it's quite time
00:22:55.799
consuming for maintainers upfront when
00:22:58.919
an incident occurs it takes a
00:23:01.080
significantly more time to diffuse the
00:23:03.600
situation education and affects all
00:23:06.179
consumers of the gem and not just the
00:23:08.820
gem maintainer
00:23:10.860
another thing that helped is the point
00:23:13.020
that others are doing the same it's
00:23:15.240
becoming an industry standard no one
00:23:17.820
wants to feel like they're the odd ones
00:23:19.860
out for our case along with ruby gems
00:23:23.340
other package managers are implementing
00:23:25.980
this policy like npm release their
00:23:29.220
policy to require MFA for the top 100
00:23:32.100
gem indicators Pi Pi was going ahead
00:23:35.220
with their policy and GitHub announced
00:23:38.039
that they'll require MFA
00:23:40.500
to all their users by the end of 2023
00:23:44.960
when they one other thing that helped
00:23:47.880
was that there was a support from
00:23:51.539
trusted people from the community it's
00:23:54.059
human nature to trust someone if they're
00:23:56.700
known to the Ruby community and it was
00:23:59.940
great that people like that added their
00:24:02.700
support and with doing all of those
00:24:05.220
things the RSC was merged in March yay
00:24:11.039
um and in June we announced the policy
00:24:14.520
to everyone and we notify users that own
00:24:18.299
a gem with more than 165 million
00:24:21.600
downloads that they should think about
00:24:25.919
uh enabling MFA so they'll see
00:24:28.760
recommendations on the web and command
00:24:32.100
line we also set emails to these
00:24:34.919
affected users and in August we started
00:24:38.640
to require users that own at least that
00:24:42.360
have a gem that has at least 180 million
00:24:46.260
downloads to have MFA enabled
00:24:51.500
we again announced this change and
00:24:54.360
started to protect actions if users
00:24:57.000
don't have MSA enabled
00:24:59.820
during this period as well we dedicated
00:25:02.460
some time to add features to API keys
00:25:05.700
that was suggested so now you can scope
00:25:08.760
an API key to a particular Gem and
00:25:12.600
toggle if that key would have MFA or not
00:25:18.059
and the feedback from the community was
00:25:20.700
shockingly very positive most if not
00:25:23.580
everyone saw the need for this change
00:25:25.679
and happy that this is one of the first
00:25:28.020
steps we're taking to secure the supply
00:25:30.539
chain
00:25:32.520
um so it's out the top 100 geminine
00:25:36.419
heaters are required to enable MFA
00:25:39.480
but what's next in store as mentioned
00:25:43.140
before this is just the start of rolling
00:25:45.480
out MFA and preventing account takeovers
00:25:48.539
in ruby gems one piece of feedback that
00:25:52.679
was raised during the release was people
00:25:55.559
want Securities key support using
00:25:59.340
security keys and biometric devices are
00:26:02.400
easier to use than totps because it's
00:26:06.120
just a simple touch rather than
00:26:08.340
frantically memorizing a six digit code
00:26:11.159
and typing it in the field they are also
00:26:15.299
safer because they are harder to fish
00:26:18.919
and to roll out the policy to other
00:26:22.919
users we want to make sure that MFA
00:26:25.799
enabling MFA is seamless as possible we
00:26:29.940
are working on adding the support
00:26:31.679
currently another aspect that needs to
00:26:35.400
be investigated is exploring ways that
00:26:38.340
for C CI in automations to safely
00:26:42.059
perform actions on behalf of the user
00:26:45.000
doing this would help raise the bar and
00:26:47.880
make sure all privileged actions would
00:26:50.100
be secured and lastly before we roll out
00:26:53.820
to more users gem maintainers are just
00:26:56.279
humans they can lose their second factor
00:26:58.760
to require MFA to potentially all users
00:27:03.000
there needs to be a sustainable process
00:27:05.460
to support these MFA resets
00:27:08.480
Ruby John's currently responds to these
00:27:11.279
requests on a voluntary basis
00:27:14.419
yeah and to fund this work just recently
00:27:19.860
Ruby Central announced a partnership
00:27:22.440
with Shopify where Shopify is donating 1
00:27:25.559
million USD over four years to fund a
00:27:29.640
security work on Ruby Johnson this is
00:27:32.039
included
00:27:33.299
so yeah that's all I have for you we
00:27:36.539
explored the past of ruby gems MFA and
00:27:40.020
why it's important the present what the
00:27:43.500
MFA landscape looks like now with the
00:27:46.260
policy rolled out and we talked about
00:27:48.179
the future and what's next
00:27:51.240
at the beginning of this talk we saw
00:27:53.520
that not many people knew what goiter
00:27:55.980
was
00:27:56.760
the reason for that is that it's become
00:27:59.279
something so rare for someone to have
00:28:01.880
hopefully one day in the future we can
00:28:04.919
say the same for account takeovers and
00:28:07.799
supply chain attacks so if there's
00:28:10.919
anything you can do after this talk is
00:28:13.320
to enable MFA
00:28:15.260
no matter how many gem downloads your
00:28:18.059
gem has enabling MFA is the best
00:28:21.179
practice and if you're not even a gem
00:28:23.520
maintainer just enable MFA on all your
00:28:26.580
accounts
00:28:27.740
since you're since you all made it to
00:28:30.600
the end of my talk I also got some
00:28:33.179
stickers to give out for those who have
00:28:36.120
who enable MFA they were designed by my
00:28:39.600
colleague Betty and they're honestly so
00:28:41.640
cute so enable MFA
00:28:43.980
um feel free to grab one after and yeah
00:28:46.860
thank you for listening um I like to
00:28:48.840
thank Ashley Betty and jock from my team
00:28:51.659
and the Ruby Jones maintainers at dtn
00:28:55.080
Joseph for helping
00:28:57.059
um roll this out if you have any
00:28:59.820
questions or like to chat I would love
00:29:02.520
to me afterwards yeah thank you